Re: [Development] Issues with QPainter::drawPolygon (off by one error?)

[Christian Ehrlicher via Development]

Am 28.04.2024 um 13:50 schrieb Allan Sandfeld Jensen:

I think the problem with the cosmetic pen is partly the need to be symmetric.
Years ago I tried cleaning up the cosmetic pen, but had to revert it because
it violated rules about symmetry.

https://codereview.qt-project.org/c/qt/qtbase/+/200383

Though perhaps the non-cosmetic painting could have the rounding adjusted so
it would look better for your example. Otherwise try offsetting the triangle
by 0.5


I think I found a valid solution now:
https://codereview.qt-project.org/c/qt/qtbase/+/557989
The call to QPainter::drawPoints() is really strange - it is only needed
for the lower left edge when drawing PE_IndicatorArrowLeft on my system
here but I can't tell if it's diffferent for other sizes or systems... :(

Thx,
Christian
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Issues with QPainter::drawPolygon (off by one error?)

[Christian Ehrlicher via Development]

Am 26.04.2024 um 22:48 schrieb Henry Skoglund:

On 2024-04-26 21:52, Christian Ehrlicher via Development wrote:

Hello,

I'm currently trying to investigate a painting problem within the
windowsvista / common style:

    QImage img(7, 7, QImage::Format_ARGB32_Premultiplied);
    QPolygon poly{ QPoint(1, 1), {5, 1}, {3, 5} };
    QPainter p();
    p.setPen(Qt::NoPen);
    p.setBrush(QColor(Qt::black));
    p.drawPolygon(poly);
    p.setPen(QColor(0, 255, 0, 128));
    p.drawPoints(poly.data(), poly.size());
    p.end();
    img.save("output.png");
...


Hi, I think the QPainter draws very poorly using direct polygon paths.
You could try going via a QPainterPath, say:

    QImage img(7, 7, QImage::Format_ARGB32_Premultiplied);
    img.fill(QColor(0, 255, 0, 128));    // to be sure the img
contains no junk values
    QPolygon poly{ QPoint(1, 1), {5, 1}, {3, 5} };
    QPainter p();
    p.setPen(Qt::NoPen);
    p.setBrush(QColor(Qt::black));
    p.setPen(QColor(0, 255, 0, 128));
    QPainterPath path;
    path.addPolygon(poly);
    p.drawPath(path);
    p.end();
    img.save("output.png");

Rgrds Henry



This helped a little bit but it then fails again for other sizes. It's a
mess :(
I'm shortly before drawing the triangles pixel by pixel by myself...


Christian
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Issues with QPainter::drawPolygon (off by one error?)

[Christian Ehrlicher via Development]

Hello,

I'm currently trying to investigate a painting problem within the
windowsvista / common style:

    QImage img(7, 7, QImage::Format_ARGB32_Premultiplied);
    QPolygon poly{ QPoint(1, 1), {5, 1}, {3, 5} };
    QPainter p();
    p.setPen(Qt::NoPen);
    p.setBrush(QColor(Qt::black));
    p.drawPolygon(poly);
    p.setPen(QColor(0, 255, 0, 128));
    p.drawPoints(poly.data(), poly.size());
    p.end();
    img.save("output.png");

This code should draw a small down arrow (e.g. for a QPushButton with a
QMenu attached) and should look similar to this:

  0123456
0
1  X
2   XXX
3   XXX
4    X
5    X
6

But the outcome is this:

  0123456
0
1  
2   XX
3   XX
4
5
6

Setting a non-cosmetic pen at least result in painting of all three
corners but gives a non-symmetric triangle:

  0123456
0
1  X
2  
3   XXX
4   XX
5    X
6

I've no idea how to draw this triangle the way I want (and everyone is
satisfied with the outcome). Do you have any ideas?


Thx,
Christian

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Documentation and Q_GADGET / Q_PROPERTY

[Christian Ehrlicher via Development]

Hi,

In the sql module I've some classes which do not derive from QObject but
have a lot of setters/getters. For a nicer documentation without
duplicating information I had the idea to convert them to properties.
So I added Q_GADGET and a simple Q_PROPERTY with only a READ and WRITE
property - but this will for sure trigger a clazy warning because there
is no NOTIFY (did not tried it by myself).
Adding a signal for all those is counter-productive as you e.g. don't
want a signal emitted for every property in QSqlField created by a query...

So what's your opinion for this case? I liked the idea to compact the
documentation by using properties but not when I have to add a lot of
additional boilerplate...

See e.g. https://codereview.qt-project.org/c/qt/qtbase/+/528482

Cheers,
Christian
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Future of java-style iterators?

[Christian Ehrlicher]

Hi,

Some days ago we got an error report in the forum about QHashIterator,
turned out to be a missing documentation for a complete class which
remained unnoticed since Qt 6.0
(https://bugreports.qt.io/browse/QTBUG-119461).
This leads to the question if we should deprecate all java-style
iterators since they seem to be a) not widely used and b) it looks like
we don't support them in a way we should.
What do you think?


Cheers,
Christian


--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt code browser url changed (cgit <-> cgit.cgi)?

[Christian Ehrlicher]

Hi,

today there was a thread on stackoverflow which mentions that the links
to the examples don't work anymore. The links in the docs (and also in
the source repo) are

https://code.qt.io/cgit/qt/qtbase.git/tree/examples/widgets/...

But it needs to be

https://code.qt.io/cgit.cgi/qt/qtbase.git/tree/examples/...


Did something changed recently wrt this? Do you need a bug report for it?


Thx,

Christian

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[Christian Ehrlicher]

Am 22.03.2023 um 20:48 schrieb Volker Hilsheimer:

Indeed, the many hits in the sql code are mostly from warning output, thanks 
for checking.

But that Postgres supports UTF-8 doesn’t mean that an existing server is also 
configured to use it. If a server is configured to work with e.g. ISO_8859_5 
encoding, because all Qt clients (which are likely middleware servers, so fully 
controlled) run on Windows machines with a corresponding code page, then Qt 
deciding to encode in UTF-8 instead will break things, won’t it? And SQL is 
just one example.


No, the client encoding is completely unrelated to the encoding on the
server and the database. All three can differ. Even informix supported
this already 15 years ago iirc. The conversion happens between the
client and server.


Christian

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[Christian Ehrlicher]

Am 22.03.2023 um 18:58 schrieb Christian Ehrlicher:

Am 22.03.2023 um 17:35 schrieb Volker Hilsheimer via Development:

  But we use toLocal8Bit in plenty of cases as well. For instance in
our Qt SQL APIs.


The only plugin which really uses toLocal8Bit() is the IBase - Plugin.


Correction: it's only used during open() and for the event notification.


Cheerst,

Christian

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[Christian Ehrlicher]

Am 22.03.2023 um 17:35 schrieb Volker Hilsheimer via Development:

  But we use toLocal8Bit in plenty of cases as well. For instance in our Qt SQL 
APIs.


The only plugin which really uses toLocal8Bit() is the IBase - Plugin.
Postgres is using it as fallback but according the docs the utf-8
encoding is supported by at least PostgreSQL 7.3 so the non utf-8 part
should be removed.

The other usages are for qWarning() output.


Will take a look on the IBase stuff to see if we can replace it.


Cheers,

Christian

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Gerrit - Staged changes not integrating since last hickup?

[Christian Ehrlicher]

Hi,

my staged changes from this morning did no longer show up in my overview
and were stuck. I had to unstage + stage them to get them integrated.

So if you had staged changes this morning you should check to see if
they are also stuck.


Cheers,

Christian

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QString, QVariant and QSQLite

[Christian Ehrlicher]

Am 26.05.2021 um 21:39 schrieb Alberto Mardegan:

Hi there!
   I'm encountering some sort of memory corruption issue in a library I'm
using, which does not cause a crash, but rather a QSQLite query to
sometimes simply return no results, without errors or warnings.

You can find the valgrind trace here:
https://git.sailfishos.org/mer-core/qtcontacts-sqlite/issues/7#note_90394

What is happening is that we bind a couple of SQLite parameters to a
prepared query. The first bound parameter is a QString.


Your observation looks correct even though I wonder why this was never
found before since this was not changed since the initial Qt5 import :)
What Qt version do you use?
Please fill a bug report with a minimal, compilable example.

Thx,
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Usage of final keyword in Qt6

[Christian Ehrlicher]

Hi,

while discussing QTBUG-89423 /
https://codereview.qt-project.org/c/qt/qtbase/+/326658 the question
about the final keywords arised - I know that I once wanted to use it in
Qt5 and it was not allowed back then. Are there any reasons to not use
final for internal classes/functions in Qt6?


Thx,
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Christian Ehrlicher]

Am 24.04.2020 um 09:22 schrieb Lars Knoll:

e "vector is a silly name from a mathematical standpoint" argument is valid, 
but vector is an established term in C++ world. Sorry, that ship has sailed.
I am also in favor of proposal 2 or 3. I think deprecating either QList or 
QVector without any big advantage for the user will just make porting form Qt5 
to Qt6 needlessly harder.

Even inside Qt we are struggling to keep up with deprecation warnings (Thanks to Friedemann for 
fixing these). I am pretty sure Creator does have the same "problem". Extrapolating that 
from "just us" to the broader audience we are hopefully targetting, it looks like lots of 
users/applications will be hit by these warnings and it will mean (lots of?) work for them.

I do agree that we shouldn’t deprecate neither name, as that would just make 
moving from 5 to 6 harder. The unification of the classes should help simplify 
things.

But we need to have a consistent message around which name is the preferred one 
and used in Qt’s own API and documentation. Having a QList in one method and a 
QVector in the next one would only be confusing to our users. So IMO this 
thread should mainly be about deciding what the default name for this container 
is in our documentation and API in Qt 6.

Since you tell everyone since ages that QList should not be used (it's
in the documentation since 5.6:
https://doc-snapshots.qt.io/qt5-5.9/qlist.html#details , Marc wrote
about not using QList in 2010 ) and the discrepancy between std::list
and QList I don't understand what's to be discussed here at all.


Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Christian Ehrlicher]

Am 02.02.2020 um 01:00 schrieb Иван Комиссаров:

I would also like to add the argument about templates. Qt API is still
incompatible with STL in some places, so one cannot write a template
function that simply calls STL variant.
For example:
QString foo;
if (std::empty(foo)) // oops, fails to compile because QString misses
the .empty() method

Of course, in the user code we can just call .isEmpty()… but if we’re
writing a template function that accepts QString and std::vector, what
should we call?
Note that std::string misses .isEmpty() method, so there’s simply no
common subset that can be used. Ofc, one can check if .size() is 0,
but I guess more examples can be found (that’s the one I was annoyed
with).


So where is your patch to add this functionality?


Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] MYSQL / MariaDB pre-build plugins

[Christian Ehrlicher]

Am 30.12.2019 um 16:52 schrieb Kevin Kofler:

Current Qt 5 (and I presume and hope, Qt 6) just works as shipped, i.e., it
can be built against current MariaDB libraries without any patches.

With this patch also on Windows:
https://codereview.qt-project.org/c/qt/qtbase/+/285384


A separate MariaDB plugin would only make things more complicated and
needlessly break backwards compatibility.

Thx for the info.


Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] MYSQL / MariaDB pre-build plugins

[Christian Ehrlicher]

Am 30.12.2019 um 15:13 schrieb Thiago Macieira:

   - do we need a small paragraph in the documentation why we can't ship
it anymore and that MariaDB should be preferred?

Yes. Just ship the MariaDB one.

Can you explain why this isn't done now?

Maybe since nobody cares? Don't know. That's why I bring it up here.


  Why can't we build against the
MariaDB libraries and ship those, with their ability to connect to MySQL
servers?

Is the issue the SONAME that the library comes under? That you have to choose
at link time which one of the two you want, meaning the one that needs to be
present at runtime? If so, my recommendation stands: use MariaDB.

Yes, they're using symlinks from libmysqlclient.so to libmariadb.so.3:
> ll /usr/lib64/libmysqlclient*
lrwxrwxrwx 1 root root 15 16. Dez 12:11 /usr/lib64/libmysqlclient_r.so
-> libmariadb.so.3
lrwxrwxrwx 1 root root 15 16. Dez 12:11 /usr/lib64/libmysqlclient.so ->
libmariadb.so.3

> ldd plugins/sqldrivers/libqsqlmysql.so
    ...
    libmariadb.so.3 => /usr/lib64/libmariadb.so.3 (0x7fabaec5b000)

And on windows it's currently not possible to link against mariadb since
the (import) libs are named libmariadb.

Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] MYSQL / MariaDB pre-build plugins

[Christian Ehrlicher]

Hi,

due to the fact that the pre-built MYSQL plugin can no longer be shipped
with the Qt installer we get a lot of questions in the forum why it's
not shipped anymore and how to build this driver from the sources. We
already tried to improve the documentation for it but it's not an ideal
solution and generates a lot of annoyance to the user.

Therefore I though it would be better to create a new plugin for MariaDB
even the MYSQL plugin works fine with MariaDB (and vice versa afaik) -
this way it should be possible to provide a pre-compiled plugin again.
Creating this plugin is easy as the code for MYSQL and MariaDB is
basically the same ( see
https://codereview.qt-project.org/c/qt/qtbase/+/283579 )
But there are still some open questions:
 - do we want to have a separate plugin for MariaDB?
 - do we need to split the sources for the MariaDB and MYSQL plugin?
 - should they be co-installable (since they use the same library names
this may not work that easily)
 - do we need a small paragraph in the documentation why we can't ship
it anymore and that MariaDB should be preferred?

Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Notes from "Releasing" session in QtCon19

[Christian Ehrlicher]

Am 20.11.2019 um 15:11 schrieb Kai Köhne:

Hi,

I took the notes for the "Releasing" Session we just had at the Qt Contributor 
Summit 2019: https://wiki.qt.io/Qt_Contributor_Summit_2019_-_Releasing_Notes

High level summary:
* The Releasing Dashboard [1] in JIRA provides a good overview of upcoming 
releases, Qt Creator releases will be added there, too.
* We should list all contributors of a release in the ChangeLog (AP Jani 
Heikkinen)
* Let's encourage people to help editing ChangeLogs (gerrit in-editing) (AP 
everyone)
* Next time for release meeting (cancellations) will be (also) announced in IRC 
channel topic (AP Jani Heikkinen)

The script creating the changlog still oversees a lot of QTBUG -
entries. I could not find out why the bug number is sometimes added to
the changelog entry and sometimes doesn't.
See for example
https://codereview.qt-project.org/c/qt/qtbase/+/281862/2..3/dist/changes-5.14.0

Cheers,
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtCS19 Notes: Qt 6 Network Overview

[Christian Ehrlicher]

Am 22.11.2019 um 15:18 schrieb Timur Pocheptsov:

Before moving to QtNetwork it needs to be significantly refactored

Can we maybe create a sub-task for this to elaborate what's meant with
'significantly refactored'?

Thx,
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Release and bugfix

[Christian Ehrlicher]

Am 18.09.2019 um 14:13 schrieb Jani Heikkinen:

-Original Message-
From: Development  On Behalf Of
Fausto Papandrea
Sent: keskiviikko 18. syyskuuta 2019 13.39
To: development@qt-project.org
Subject: [Development] Qt Release and bugfix

Good morning,

I have to update my Qt version because of this bug
https://bugreports.qt.io/browse/QTBUG-74076.

The bug is marked as resolved in Qt 5.12.4, but, is it merged in Qt 5.13/5.13.1?

Yes, fix was initially integrated in '5.12' and '5.12' is merged to '5.13' from 
where it is then went in Qt 5.13.0 and future releases

If you want to see where the patch is currently available just click on
the review ( https://codereview.qt-project.org/c/qt/qtbase/+/259142 )
and then on 'Included In'.

HTH,
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Christian Ehrlicher]

Am 13.06.2019 um 23:44 schrieb Konstantin Tokarev:


14.06.2019, 00:14, "Christian Ehrlicher" :

Am 13.06.2019 um 22:09 schrieb Ville Voutilainen:

  That's one of the things I love about Qt; object hierarchies give me
  working dynamic memory management without needing even smart pointers.

  That's the one thing that makes me queasy about using Qt in large
  applications; I always need
  to worry about ownership relationships, because I can't program with
  smart pointers. I had the pleasure
  of writing smart-pointer-only code 20 years ago; it was quite
  pleasant, especially considering that
  the largeish application was leaking like a sieve and doing
  use-after-free in all too many places.
  Once we plugged boost's smart pointers into it, all those problems
  went away over a weekend,
  and we never looked back.

A very good example on how to kill a library by simply using smart
pointer everywhere is QtXmlPatterns:

https://bugreports.qt.io/issues/?jql=project%20%3D%20QTBUG%20AND%20status%20%3D%20Reported%20AND%20component%20%3D%20%22XML%3A%20QtXmlPatterns%22%20ORDER%20BY%20key%20DESC

Any proffs that any of these issues were caused by smart pointers?

Otherwise I would not have mentioned it. Just take a look at the code
and one of the bug report issues... it awesome and you will see why
nobody want/can maintain this library.

Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Christian Ehrlicher]

Am 13.06.2019 um 22:09 schrieb Ville Voutilainen:

That's one of the things I love about Qt; object hierarchies give me
working dynamic memory management without needing even smart pointers.

That's the one thing that makes me queasy about using Qt in large
applications; I always need
to worry about ownership relationships, because I can't program with
smart pointers. I had the pleasure
of writing smart-pointer-only code 20 years ago; it was quite
pleasant, especially considering that
the largeish application was leaking like a sieve and doing
use-after-free in all too many places.
Once we plugged boost's smart pointers into it, all those problems
went away over a weekend,
and we never looked back.

A very good example on how to kill a library by simply using smart
pointer everywhere is QtXmlPatterns:

https://bugreports.qt.io/issues/?jql=project%20%3D%20QTBUG%20AND%20status%20%3D%20Reported%20AND%20component%20%3D%20%22XML%3A%20QtXmlPatterns%22%20ORDER%20BY%20key%20DESC

So simply saying 'smart pointer fix it all' is just wrong.


Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Dropping sqlite2 plugin for Qt6/cmake port

[Christian Ehrlicher]

Am 03.05.2019 um 12:34 schrieb Lars Knoll:

+1 from my side. Please deprecate sqlite2 for 5.14 if that hasn’t been
done yet.

Did not find something in the docs so:
https://codereview.qt-project.org/#/c/260672/

Cheers,
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] On deprecating functions

[Christian Ehrlicher]

Am 05.03.2019 um 11:53 schrieb Tor Arne Vestbø:

On 5 Mar 2019, at 11:27, Giuseppe D'Angelo via Development 
 wrote:

Il 05/03/19 08:14, Lars Knoll ha scritto:

One solution I thought about is to replace the QT_DEPRECATED(_X) macros with 
something that also contains the version (similar to QT_DEPRECATED_SINCE). Then 
the user could define how current he wants to be, and we could set a reasonable 
default going e.g. one LTS back.

I'd go with this one. Should make everyone happy. Can anyone see any adverse 
effect?

I also prefer this one.
Here a possible implementation for discussion, tested with the new 
QComboBox changes:

https://codereview.qt-project.org/255051

Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] On deprecating functions

[Christian Ehrlicher]

Am 05.03.2019 um 00:37 schrieb André Pönitz:

On Mon, Mar 04, 2019 at 03:12:33PM -0800, Thiago Macieira wrote:

On Monday, 4 March 2019 13:48:25 PST André Pönitz wrote:

The proposed model would effectively introduce another user-visible
level including associated period of time between "alternative
solution gets introducd" and "getting nagged about not using it"
that is "hopefully" long enough, to cover "most interesting"
(to be blunt: read: "including my") use case.

I don't think we should deprecate things, much less warn about, until there's
a suitable example, except in few cases where the API was mis-designed and has
no solution. That doesn't mean the solution needs to be a simple search-and-
replace, but it needs to exist.

Does that change what you're proposing?

There's a difference in so far that I request a certain period of time
(or rather, a span of Qt versions) both, old and new version, compile
and do not cause a warning in a default Qt build.
We could add a new define similar to QT_DISABLE_DEPRECATED_BEFORE - 
QT_DEPRECATED_WARNINGS_BEFORE which is by default initialized to the 
same value as QT_DISABLE_DEPRECATED_BEFORE but can be set to something 
else if needed.



Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] On deprecating functions

[Christian Ehrlicher]

Am 04.03.2019 um 19:28 schrieb Thiago Macieira:

On Monday, 4 March 2019 09:58:40 PST Edward Welbourne wrote:

Christian Ehrlicher (4 March 2019 17:51) wrote


So what's the correct way to deprecate a function and not forgetting
about QT_DEPRECATED later on as it happened with a lot of functions
during Qt4 times?

Isn't that what
#if QT_DEPRECATED_SINCE(5, 13)
is for ?

The point raised by hjk is that this causes warnings to anyone compiling code
that needs to retain compatibility. There's no grace period. This is probably
why we only documented the functions were deprecated with \obsolete, but never
enabled warnings (except for Qt4-compat things). In that scheme, finding
deprecated functions is done by raising QT_DEPRECATED_SINCE in your
buildsystem and see what fails, instead of having warnings printed at you.

Should we go back to this?
You know what happens in this case - nothing since noone notices... see 
all the usages of deprecated functions within QtBase which have been 
unrecognized for ages.
Lars mentioned a new macro Q_WARN_DEPRECATED_SINCE(major, minor) here: 
https://codereview.qt-project.org/#/c/254857/ - maybe this could help here?



Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] On deprecating functions

[Christian Ehrlicher]

Hi,

I recently introduced some new signals (Q(Double)SpinBox::textChanged, 
QComboBox::textActivated) as replacements for old ones to be able to 
avoid the use of QOverload<>::of in Qt6 and to better match their 
respective properties.
Within those changes I also marked the old signals as deprecated with 
QT_DEPRECATED so the developer gets an information to no longer use this 
function in new code.
This lead to a lot of warnings in old code which needs to be compiled 
with 5.9 and 5.12 (e.g. in QtCreator) which can't be fixed because there 
the new function is not yet available. It was requested to remove the 
QT_DEPRECATED decoration until e.g. 5.15. but I think then it's too 
later to be able to remove them with Qt6.
See https://codereview.qt-project.org/252208 for the discussion and a 
possible solution here: https://codereview.qt-project.org/#/c/254909/


So what's the correct way to deprecate a function and not forgetting 
about QT_DEPRECATED later on as it happened with a lot of functions 
during Qt4 times?



Thx,
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Gerrit run out of disk space?

[Christian Ehrlicher]

Hi,

gerrit is very slow this evening and now that I wanted to push a change 
I got this messages from git:


fatal: Unpack error, check server log
Counting objects: 18, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (18/18), done.
error: remote unpack failed: error No space left on device

So who pushed such a big patch to fill up the disk space on gerrit? ;)


Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] All deprecation warnings are P1 for 5.13.0

[Christian Ehrlicher]

Am 09.02.2019 um 18:02 schrieb Thiago Macieira:

On Saturday, 9 February 2019 07:30:36 PST Christian Ehrlicher wrote:

QT_DISABLE_DEPRECATED_BEFORE=0x051300:

Uh, that's 0x050d00 :-)
Ah, this explains why I also got warnings/erros about functions which 
got deprecated in 5.14 :)



Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] All deprecation warnings are P1 for 5.13.0

[Christian Ehrlicher]

Am 09.02.2019 um 02:27 schrieb Thiago Macieira:

By beta, those that aren't fixed will get P1 bug reports in JIRA.

for qtbase/src - feel free to review them :)

https://codereview.qt-project.org/252626
https://codereview.qt-project.org/252627
https://codereview.qt-project.org/252628
https://codereview.qt-project.org/252629
https://codereview.qt-project.org/252630
https://codereview.qt-project.org/252631
https://codereview.qt-project.org/252632
https://codereview.qt-project.org/252633

There are a few places left which don't compile with 
QT_DISABLE_DEPRECATED_BEFORE=0x051300:

 - QDialog::setVisible() due to showExtension()
 - QPainter::initFrom() - I'm not sure if the function should really be 
deprecated...

 - QComboBox::setLineEdit() due to setAutoCompletion()
 - QAlphaWidget - the parent is a QDesktopWidget - I'm not sure if this 
really works with Qt5 at all - remember I had problems with this approach.


Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] All deprecation warnings are P1 for 5.13.0

[Christian Ehrlicher]

Am 09.02.2019 um 10:00 schrieb Allan Sandfeld Jensen:

By beta, those that aren't fixed will get P1 bug reports in JIRA.

By fixed I guess you also mean suppressed were appropriate? some are from
tests testing deprecated functions, and other are deprecated functions calling
other deprecated functions because they belong together.
I learned about QT_WARNING_DISABLE_DEPRECATED to work around this e.g. 
here: 
https://codereview.qt-project.org/#/c/252330/3/tests/auto/widgets/itemviews/qlistwidget/tst_qlistwidget.cpp

Not sure if this is feasible for all situations though.

Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] All deprecation warnings are P1 for 5.13.0

[Christian Ehrlicher]

Am 09.02.2019 um 07:34 schrieb Giuseppe D'Angelo via Development:

Hi,

Il 09/02/19 02:27, Thiago Macieira ha scritto:

Commit 7847e6bc02552fa7fc7f518e5cb3336f667b5a6d in qtbase madee the
QT_DEPRECATED and QT_DEPRECATED_X warnings on by default in Qt 
builds. That

means we started seeing lots of warnings that weren't there in 5.12.


Agree with the rest of the email. From a purely technical point of
view, however, I'm wondering why we didn't see those warnings before? 
Qt was already built with warnings enabled AFAICS? For instance:
It was only enabled for src, not for examples and tests so I did not saw 
the warnings before your commit I would guess. So even functions which 
were already marked deprecated for a long time did not trigger warnings. 
Fixing all the examples and tests before 5.13beta is ... challenging. 
And doing this for anything other than qtbase is not possible for me 
during my limited time.



Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Deprecation of QByteArray operator const char *()?

[Christian Ehrlicher]

Am 26.01.2019 um 08:22 schrieb Olivier Goffart:

On 25.01.19 21:11, Christian Ehrlicher wrote:

Hello,

The two implicit conversions from QByteArray to const char*/void* 
(QByteArray::operator const char *() and QByteArray::operator const 
void*()) were marked as obsolete with Qt5.0 but never get decorated 
as such. This means their usage even inside QtBase is huge (I would 
say at least 70-80 locations).
Therefore my question before I'm pushing a patch to add 
QT_DEPRECATED_X to them - is the deprecation still valid?


I count 4331 uses

https://code.woboq.org/data/symbol.html?root=../qt5/=_ZNK10QByteArraycvPKcEv 



That's a bit more than 70-80

I talked about QtBase, not Qt5 :)
But this even makes the un-deprecation more useful.

Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Deprecation of QByteArray operator const char *()?

[Christian Ehrlicher]

Am 25.01.2019 um 21:23 schrieb Thiago Macieira:

On Friday, 25 January 2019 12:11:33 PST Christian Ehrlicher wrote:

Hello,

The two implicit conversions from QByteArray to const char*/void*
(QByteArray::operator const char *() and QByteArray::operator const
void*()) were marked as obsolete with Qt5.0 but never get decorated as
such. This means their usage even inside QtBase is huge (I would say at
least 70-80 locations).
Therefore my question before I'm pushing a patch to add QT_DEPRECATED_X
to them - is the deprecation still valid?

I'd un-deprecate them. The use to casting to char* is way too useful.

But I wasn't aware we event had a void* cast.
Here the commit which deprecated the functions: 
https://codereview.qt-project.org/#/c/17343/
I found one place inside QtBase which hit this problem: 
https://codereview.qt-project.org/#/c/251028/


Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Deprecation of QByteArray operator const char *()?

[Christian Ehrlicher]

Hello,

The two implicit conversions from QByteArray to const char*/void* 
(QByteArray::operator const char *() and QByteArray::operator const 
void*()) were marked as obsolete with Qt5.0 but never get decorated as 
such. This means their usage even inside QtBase is huge (I would say at 
least 70-80 locations).
Therefore my question before I'm pushing a patch to add QT_DEPRECATED_X 
to them - is the deprecation still valid?



Thx,
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Issues with 'Fixes' keyword

[Christian Ehrlicher]

Am 27.12.2018 um 10:52 schrieb Allan Sandfeld Jensen:

It has been for me. I always put bugs I have a patch in review for "in
progress", and they have been consistently closed, except one time I found a
bug in the script that was then closed. You have probably run into another
bug. What else was special in this case?
I did not saw an obvious difference. Looks like there are others which 
are not closed in reporting state: 
https://bugreports.qt.io/browse/QTBUG-48505
Maybe they're all in dev? At least my last ones for 5.12 were closed 
automatically.



Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Issues with 'Fixes' keyword

[Christian Ehrlicher]

Am 27.12.2018 um 07:43 schrieb Kari Oikarinen:

On 26.12.2018 17.58, Christian Ehrlicher wrote:

Hi,

looks like under some circumstances the 'Fixes' keyword in the commit message
does trigger the automatic closing of a bug when the bug is in 'In progress'
state. Is this the intended behavior?

Yes. You can use the "Task-number" keyword if you want to link commits to a bug,
but still keep it open. For example if fixing it properly requires multiple
changes.
Ah, I forgot a 'not'... Bugs in 'In Progress' state and with a 'Fixes' 
keyword are *not* automatically closed.



Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Issues with 'Fixes' keyword

[Christian Ehrlicher]

Hi,

looks like under some circumstances the 'Fixes' keyword in the commit 
message does trigger the automatic closing of a bug when the bug is in 
'In progress' state. Is this the intended behavior?


Here some examples:
https://bugreports.qt.io/browse/QTBUG-72545
https://bugreports.qt.io/browse/QTBUG-44746

Thx,
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Christian Ehrlicher for Approver

[Christian Ehrlicher]

Am 11.12.2018 um 09:51 schrieb Alex Blasche:

Hi,

Congratulations to Christian. Approver rights have been granted.


Thanks! :)


Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Ehrlicher]

Am 30.10.2018 um 09:21 schrieb resurrect...@centrum.cz:


// // set(var1 "Hello")

// // set(var2 "Hello")

// //

// // if(var1 EQUAL var2)

// //  message("They are equal")

// // endif()

Using STREQUAL works here for me with cmake 3.12 on linux so if it does 
not work for you please file a bug report in the cmake bugtracker.


set(var1 "Hello")
set(var2 "Hello")
set(var3 "Hello2")
if(var1 STREQUAL var2)
    message("They are equal")
endif()
if(NOT var1 STREQUAL var3)
    message("They are *NOT* equal")
endif()

Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Ehrlicher]

Am 30.10.2018 um 06:29 schrieb resurrect...@centrum.cz:


set(var1 "Hello")

set(var2 "Hello")

if(var1 EQUAL var2)

    message("They are equal")

endif()

Guess what, it prints NOTHING despite docs explicitly saying this 
should work. Nothig will help, STREQUAL, MATCHES, dereferencing the 
arguments, whatever.



You read the docs wrong:
EQUAL: True if the given string or variable’s value is a valid number 
and equal to that on the right.

Neither var1 nor var2 is a valid numbers.

You want
if (var1 STREQUAL var2) and this works as expected (and documented).

//
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Deprecated functions / procedure of removal in Qt6?

[Christian Ehrlicher]

Am 22.10.2018 um 00:14 schrieb Giuseppe D'Angelo via Development:

Hi,

Thus, adding deprecation warnings is definitely the right thing to do: 
users get the deprecation warnings (*), and we have an easy way to 
find and drop all those functions.


Ok, I'll go on with adding Q_DECL_DEPRECATED + QT_VERSION < 
QT_VERSION_CHECK(6, 0, 0) in the places where only the documentation 
states that this function is deprecated then. Otherwise they might get 
forgotten again :)



Thx,
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Un-inlining members allowed?

[Christian Ehrlicher]

Hi,

one more question - is it ok to un-inline a function? For example I want 
to move QListWidgetItem::isSelected() to the cpp file so I can properly 
mark QListWidget::isItemSelected() as deprecated but I'm unsure if this 
is allowed.


Thx,
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Deprecated functions / procedure of removal in Qt6?

[Christian Ehrlicher]

Hi,

there are a lot of deprecated functions in qtbase which are only marked 
as deprecated/obsolete in the documentation but don't have a 
Q_DECL_DEPRECATED. Most of them were deprecated in the pre Qt5-era. 
What's the 'correct' way to make sure they can be removed with Qt6? Must 
they marked as QT_DEPRECATED_SINCE(5,x) or is the comment in the 
documentation enough?


Thx,
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Closing issues automatically with new keyword

[Christian Ehrlicher]

Am 23.09.2018 um 17:39 schrieb Christian Ehrlicher:

Hi,

I get this warning when I only add 'Fixes:' in the footer:

***
*** Suspicious changes in commit HEAD (QSqlQuery: add another testcase 
for bindBool()):

***
***   commit message:
*** - 8: Text following footers (key "footer")
***
***   See http://wiki.qt.io/Early_Warning_System for explanations.

But gerrit does not complain: 
https://codereview.qt-project.org/#/c/240736/

Ok, I thought I updated qtrepotools but it wasn't the case.


Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Closing issues automatically with new keyword

[Christian Ehrlicher]

Hi,

I get this warning when I only add 'Fixes:' in the footer:

***
*** Suspicious changes in commit HEAD (QSqlQuery: add another testcase 
for bindBool()):

***
***   commit message:
*** - 8: Text following footers (key "footer")
***
***   See http://wiki.qt.io/Early_Warning_System for explanations.

But gerrit does not complain: https://codereview.qt-project.org/#/c/240736/


Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Q_COMPILER_UNIFORM_INIT still needed?

[Christian Ehrlicher]

Hi,

will reviewing a patch I found this comment from Marc Mutz in 
qstringlistmodel.cpp:

// once Q_COMPILER_UNIFORM_INIT can be used, change to:
// emit dataChanged(index, index, {Qt::DisplayRole, Qt::EditRole});

Now I wonder if this is still needed because we're using this way 
calling dataChanged in a lot of other places without the guard and even 
in the documentation.
So - is this comment wrong or is the define no longer needed (I would 
guess the latter)



Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QEasingCurve saving to QDataStream

[Christian Ehrlicher]

Am 08.05.2018 um 20:40 schrieb Thiago Macieira:

Does anyone remember the implementation details for this class? If so, can you
help with https://bugreports.qt.io/browse/QTBUG-68181 ?

I can clearly see parameters that are not properly saved to the stream, but I
don't know which parameters need to be saved and which ones are computed only.
I'm not sure if it helps but from my pov it would be enough to 
additionally save _bezierCurves when the type is 
QEasingCurve::BezierSpline and _bezierCurves and _tcbPoints when the 
type is QEasingCurve::TCBSpline.



HTH,
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing David Faure as maintainer of Qt Models

[Christian Ehrlicher]

Hi,

 

There is already a component "Widgets: Itemviews" which should be renamed then.

 

Christian

 

Gesendet: Mittwoch, 02. Mai 2018 um 08:37 Uhr
Von: "Lars Knoll" 
An: "Alex Blasche" 
Cc: "Qt development mailing list" 
Betreff: Re: [Development] Proposing David Faure as maintainer of Qt Models

I'd say we add one line for qtbase/Qt Core/Item models in the maintainer wiki. 'Item models' would probably also be the best name for Jira.

Cheers,
Lars
 



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QVector reserve counterproductive?

[Christian Ehrlicher]

Am 04.03.2018 um 10:03 schrieb Christian Ehrlicher:

Am 03.03.2018 um 23:22 schrieb Martins, Sérgio:

On 2018-03-03 20:38, Christian Ehrlicher wrote:


But it looks like reserve()
allocates *exactly* the amount of elements given.


Actually that qpainterpath code is off-by-one, it should be:
d_func()->elements.reserve(d_func()->elements.size() + polygon.size() 
- 1);


which also fixes the performance problem (by luck, in that specific 
benchmark). Please test.
You're correct - this fixes the problem. Looks like the growth 
strategy is only applied when the current capacity == current size and 
not when the current capacity is slightly higher... good to know (and 
should maybe be documented?)
The off-by-one idea was wrong. moveTo() will add another point to 
elements - therefore reserve(d_func()->elements.size() + polygon.size()) 
is correct.
Maybe the best idea here would be to simply remove the reserve() calls 
and let QVector do what it is made for... :)



Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QVector reserve counterproductive?

[Christian Ehrlicher]

Am 03.03.2018 um 23:22 schrieb Martins, Sérgio:

On 2018-03-03 20:38, Christian Ehrlicher wrote:


But it looks like reserve()
allocates *exactly* the amount of elements given.


Actually that qpainterpath code is off-by-one, it should be:
d_func()->elements.reserve(d_func()->elements.size() + polygon.size() 
- 1);


which also fixes the performance problem (by luck, in that specific 
benchmark). Please test.
You're correct - this fixes the problem. Looks like the growth strategy 
is only applied when the current capacity == current size and not when 
the current capacity is slightly higher... good to know (and should 
maybe be documented?)


Will create a patch for qpainterpath soon.

Thx,
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QVector reserve counterproductive?

[Christian Ehrlicher]

Hi,

while digging through the bugreports I found 
https://bugreports.qt.io/browse/QTBUG-66677 which seems to show a 
downside of QVector::reserve().
QPainterPath::addPolygon() is calling reserve() to make sure to have 
enough space for the new positions. This is exactly what I would have 
done and what e.g. CLazy suggests. But it looks like reserve() allocates 
*exactly* the amount of elements given. Therefore calling addPolygon() a 
second time will do a new reallocation and so on.
The documentation for reserve() only states that memory for 'at least 
size elements' is allocated so my naive assumption would be that calling 
reserve a second time with a slightly bigger value than before does 
nothing. But this doesn't seem to be the case here.


For the bug: removing the reserve() inside addPolygon() fixes the speed 
issues mentioned in the bug report. Don't know if the bug report is a 
valid use case though.


Thx,
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QVector rvalue overloads for convenience functions?

[Christian Ehrlicher]

Hi,

recently rvalue overloads for QVector::append(T), push_back(T) and 
others were added to QVector. But not for the convenience functions like 
operator<<(T) or operator +=(T). Is this an oversight or by intention?



Thx,
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QTimer::setInterval() and

[Christian Ehrlicher]

Am 07.12.2017 um 17:01 schrieb Thiago Macieira:

So you upgrade your compiler.

No problem from my side :)


See also how no version of Visual Studio has __has_include, so the
functionality is disabled with Microsoft's compiler until they implement the
macro.

This is a conscious decision.
Then it's even more important to document that those functions are not 
available for compilers which do not support __has_include.

Really hoped this was just a leftover from pre c++11 times :)

Will fill a documentation bug report this evening.
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QTimer::setInterval() and

[Christian Ehrlicher]

Gesendet: Donnerstag, 07. Dezember 2017 um 10:37 Uhr
Von: "Giuseppe D'Angelo" 
An: development@qt-project.org
Betreff: Re: [Development] QTimer::setInterval() and 


Support for  from the Standard Library is one of the things that
Qt includes conditionally. I'm not sure which platform we want to
support doesn't have it yet (QNX? maybe osX?), and since we don't want
to drop that platform, we protect the inclusion.


Maybe this is the better question - is there any platform which does not provide proper support for  in 5.9 (or 5.10/11)?

And shouldn't the documentation state that some functions are not available, even the used compiler supports it, just because the check is using some other feature which prevents the usage...

 

 

Christian


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QTimer::setInterval() and

[Christian Ehrlicher]

Hi,

 

According to QTimer documentation, QTimer::setInterval(std::chrono::milliseconds) is available unconditionally in Qt 5.9. But in qtimer.h the std::chrono - functions are guarded with QT_HAS_INCLUDE(chrono) which expands to __has_include(chrono) or 0.

The problem is that gcc 4.8 doesn't know anything about this preprocessor construct and therefore QTimer::setInterval(std::chrono::milliseconds) is not available there. According to the gcc release notes __has_include() was introduced in gcc 5 ( https://www.gnu.org/software/gcc/gcc-5/changes.html#c-family ).

From my pov  is a c++11 feature and since Qt5.9 needs c++11 the include gueard is superfluous. But I don't know if there is a supported platform which is still supported and chrono is not available...

If the include guard is superflouos, I can create a patch.

 

btw: the same goeas for qmutex.h and qobject.h

 

Thx,

Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Problem porting app from Qt4 to Qt5 with multiple X-screen

[Christian Ehrlicher]

 Von: Christian Ehrlicher ch.ehrlic...@gmx.de
 Am 09.02.2015 um 15:35 schrieb Friedemann Kleint:
  Hi,
 
  we've multiple X-screens configured (:0.0 ... :0.3) but Qt5 seems to
  have lost the ability to display something on another screen than the
  default
   QMainWindow *wm = new QMainWindow(dw-screen(1));
 
  Change https://codereview.qt-project.org/#/c/105285/ for
  https://bugreports.qt.io/browse/QTBUG-44070[https://bugreports.qt.io/browse/QTBUG-44070]
   should improve that.
 Thx for the info. I'll check this out tomorrow and report back if my
 issues are all gone :)
Ok, now at least all widgets with a desktop widget as parent are created on the 
correct screen. But as soon as I open a child window (e.g. the file open dialog 
on my example) this is created on the applications primary screen.
Should I fill a bug report for this?


btw: Is it correct that QScreen::geometry() returns 0/0 every time (openSUSE 
13.2/Qt 5.3.2 rpm)

Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Problem porting app from Qt4 to Qt5 with multiple X-screen

[Christian Ehrlicher]

Am 09.02.2015 um 15:35 schrieb Friedemann Kleint:
 Hi,

   we've multiple X-screens configured (:0.0 ... :0.3) but Qt5 seems to
 have lost the ability to display something on another screen than the
 default
QMainWindow *wm = new QMainWindow(dw-screen(1));

 Change https://codereview.qt-project.org/#/c/105285/ for
 https://bugreports.qt.io/browse/QTBUG-44070 should improve that.
Thx for the info. I'll check this out tomorrow and report back if my 
issues are all gone :)

   embedding an application window into another application doesn't work
 correct - the embeded window gets resized with the master but as soon as
 I click somewhere in the master, the embedded window is hidden by the
 master.

 How do you embed the window?
In Qt4 I'm using QX11EmbedWidget/EmbedContainer. In Qt5 I use 
QWidget::createWindowContainer() + QWindow::fromWinId(). The simple 
testcase (a QWidget on client and server side) works as expected but I 
my application it does not work. I could not yet figure out which side 
is the problem - on the server site I want to use it as centralWidget() 
of a QMainWindow, on the client side it's a QWidget with custom 
paintings outside the paintevent. I hope to get to this tomorrow evening.

Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Problem porting app from Qt4 to Qt5 with multiple X-screen

[Christian Ehrlicher]

Hi,



Im trying to port a Qt4 application to Qt5. All works fine except two points:

- weve multiple X-screens configured (:0.0 ... :0.3) but Qt5 seems to have lost the ability to display something on another screen than the default

- embedding an application window into another application doesnt work correct - the embeded window gets resized with the master but as soon as I click somewhere in the master, the embedded window is hidden by the master.

The second problem can maybe worked around by merging the two applications into one (its on my todo) but its still a problem in qt then...



The first problem can be shown with a small testcase:

-

int main(int argc, char** argv)
{
 QApplication app(argc, argv);
 QDesktopWidget *dw = app.desktop();
 QMainWindow *wm = new QMainWindow(dw-screen(1));
 wm-winId(); // not needed with Qt4
 wm-windowHandle()-setScreen(QGuiApplication::screens().at(1)); // not needed with Qt4
 wm-show();
 QFileDialog::getOpenFileName(wm);
 return app.exec();
}
-

It looks like the parentwidgets screen is not respected when the child is created. The QMainWindow can be shown on screen 1 with the help of QWindow::setScreen() but all children of QMainWindow are displayed on the default screen instead the one where the parent lives.

I tried to dig into the sources to see whats going wrong but Im lost somewhere between QWindow and the xcb plugin... :(



Anyone an idea where to look further or what could went wrong here?



Thx,

Christian Ehrlicher




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Weird offseting in QDataStream

[Christian Ehrlicher]

Am 08.11.2013 10:15, schrieb Yves Bailly:
 Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit :
 On 8 November 2013 10:01, Yves Bailly yves.bai...@sescoi.fr wrote:
 As a float is 4 bytes, I would expect the second f.pos() to display 4... 
 but
 it displays 8, as if QDataStream had moved 8 bytes ahead instead of just 
 4.
 Needless to say, the read float is wrong...

 Am I missing something here, or is it a bug?
 See QDataStream::setFloatingPointPrecision. The default is double.
 That's pretty strange... what if I want to read a float then a double? do I
 have to switch between the two each time?
 Does this means it's impossible to use code like this:
 float f;
 double d;
 datastream  f  d;
 ?
setFloatingPointPrecision does only change the way the floating point 
numbers are stored in the data stream, not what you read from it.
Also I think you're wrong in what you want to do. You can't read data 
from a file which was not stored with QDataStream before! See 
http://qt-project.org/doc/qt-5.0/qtcore/qdatastream.html#details


Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Weird offseting in QDataStream

[Christian Ehrlicher]

Am 08.11.2013 10:42, schrieb André Somers:

Christian Ehrlicher schreef op 8-11-2013 10:29:

Am 08.11.2013 10:15, schrieb Yves Bailly:

Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit :

On 8 November 2013 10:01, Yves Baillyyves.bai...@sescoi.fr  wrote:

As a float is 4 bytes, I would expect the second f.pos() to display 4... but
it displays 8, as if QDataStream had moved 8 bytes ahead instead of just 4.
Needless to say, the read float is wrong...

Am I missing something here, or is it a bug?

See QDataStream::setFloatingPointPrecision. The default is double.

That's pretty strange... what if I want to read a float then a double? do I
have to switch between the two each time?
Does this means it's impossible to use code like this:
float f;
double d;
datastream  f  d;
?

setFloatingPointPrecision does only change the way the floating point
numbers are stored in the data stream, not what you read from it.
Also I think you're wrong in what you want to do. You can't read data
from a file which was not stored with QDataStream before! See
http://qt-project.org/doc/qt-5.0/qtcore/qdatastream.html#details
That sounds very unlikely. It would mean that you cannot use symetric 
code for reading and writing data:


//writing
float f(3.14159);
double d(2.71828);
datastream  f  d;

//reading, would not work according to Christian
float f;
double d;
datastream  f  d; //would not work according to you

//reading, according to Christian
float f;
double df, d;
datastream  df  d;
f = static_castfloat(d);

I'm quite sure that you _can_ use the symetric (first) version.


You're correct - you understood me wrong. :)

Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development