Re: [Development] Possible bug in touch event coordinates in QtWebEngine when using pixelDeviceRatio

Hi Christophe, Without commenting on the content of your patch at the moment, you just need to sign our CLA and push the change to our Gerrit Code Review system, where we can review and then hopefully integrate it. Check out https://wiki.qt.io/Qt_Contribution_Guidelines which will walk you

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Op 14-10-2015 om 15:59 schreef Matthew Woehlke: > >>> Yes, signed please. We can discuss whether it should be 64bit for Qt 6. >> The current std API uses size_t. Do you (= both of you) expect that ever to >> change? If it doesn't, Qt will forever be the odd one out, until we finally >> drop

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 2015-10-14 10:30, André Somers wrote: > Op 14-10-2015 om 15:59 schreef Matthew Woehlke: >> STL should change. In Qt and Python, you can use negative indices to >> refer to a distance (length) relative to the end (length) of the string. >> In STL you can't do that, which is a significant

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 09:59:28 Matthew Woehlke wrote: > On 2015-10-14 06:16, Marc Mutz wrote: > > First, afaiu from what Thiago mentions in reviews, Q6String will have SSO > > (small-string-optimisation) which makes many short strings expensive to > > copy (if you think that copying 24

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 08:51:11 Thiago Macieira wrote: > The separation of the string itself from the size and the d pointer allows > the compiler, if it wants to, to share strings. In fact, disassembly of > > f(QStringLiteral("foo"), QStringLiteral("foo")) > > produces one copy

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 12:16:47 Marc Mutz wrote: > > >But as a condition to be even considered, it needs to be only for the > > >methods > > >that do not hold a copy of the string. That is, methods that immediately > > >consume the string and no longer need to reference its contents. > >

Re: [Development] adding a custom entry to qmake's QT (or CONFIG?) - shared libs always linked in?

Hi, I'm getting closer to my goal, with a "true module" that can be added as "QT += qsp_xdg" or "find_package(Qt5QspXDG) ; target_link_libraries(...Qt5::QspXDG ..)" The nice thing is that I didn't even have to write a cmake file: good work there! My initial idea had been to use an object

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 20:09:56 Marc Mutz wrote: > On Wednesday 14 October 2015 12:41:12 Allan Sandfeld Jensen wrote: > > Why not a QCharArray? With external data constructor, that should be the > > same, shouldn't it? > > If you propose something like QString/QByteArray::fromRawData(),

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 20:04:12 Marc Mutz wrote: > On Wednesday 14 October 2015 18:11:26 Thiago Macieira wrote: > > and the fact that QStringLiterals don't share will cause the > > innocent-looking above code require 64 bytes of read-only data. > > They are shared, because it seems that

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 15:59:21 Matthew Woehlke wrote: > On 2015-10-14 07:15, Knoll Lars wrote: > > In addition, it might be tricky to use QStringView in signals and > > slots. > > As I previously stated, I'm pretty sure you *CAN'T* use QStringView to > call slots, except for direct call.

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 12:41:12 Allan Sandfeld Jensen wrote: > Why not a QCharArray? With external data constructor, that should be the > same, shouldn't it? If you propose something like QString/QByteArray::fromRawData(), then that allocates the control block, so no, not really an

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 18:11:26 Thiago Macieira wrote: > and the fact that QStringLiterals don't share will cause the > innocent-looking above code require 64 bytes of read-only data. They are shared, because it seems that lambdas within the same function have the same type. At least last

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 13/10/15 22:46, "Matthew Woehlke" wrote: >On 2015-10-13 15:59, Jake Petroules wrote: >> On Oct 13, 2015, at 1:46 PM, Marc Mutz wrote: >>> I would therefore like to propose to abandon QString for new API (and >>>over >>> time phase it out of existing API), and only

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

I’m not a huge fan of having different overloads with QString, QStringRef and QLatin1String and in some cases (QChar *, int) for many methods neither. But while your proposal solves some problems it introduces others. A QStringView class would only work for methods that read the data contained in

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Tuesday 13. October 2015 22:46:36 Marc Mutz wrote: > I would therefore like to propose to abandon QString for new API (and over > time phase it out of existing API), and only provide (const QChar*, size_t) > as the most general form. I would propose to package the two into a class, > called -

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 08:37:19 Knoll Lars wrote: > I’m not a huge fan of having different overloads with QString, QStringRef > and QLatin1String and in some cases (QChar *, int) for many methods > neither. But while your proposal solves some problems it introduces others. > > A QStringView

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Hi Lars Knoll Lars > Agree here as well. We can’t make QString utf-8 backed without breaking > way too much code. I also don’t see the need for it. The native encoding > on Windows and Mac (Cocoa) is utf-16 as well, on Linux it’s utf-8. So no > matter which platform

Re: [Development] New Qt Modules

Hi, It seems that the discussion is mostly completed. Next we’ll create the repos according to what was discussed. The preferred proposal for Qt QML DBus integration was not to have a new repo, but a WIP branch in qtdeclarative: qt/qtdeclarative//wip/dbus If this is fine also for the

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 17:55:34 Bubke Marco wrote: > Think about a local aware compare which is called very very often. You don't > want malloc in between. In in most cases you get an const char* or const > shor* in this cases It would be nice if your interface would support UTF-8 > and not

Re: [Development] QTime microsecond support

> On Oct 14, 2015, at 1:22 PM, Dustin Mitchell wrote: > > Hello, > > Are there plans to support microseconds in the QTime class? I need to parse > timestamps from a text file and it has microsecond resolution. If not, I'd be > willing to implement this feature. > >

[Development] QTime microsecond support

Hello, Are there plans to support microseconds in the QTime class? I need to parse timestamps from a text file and it has microsecond resolution. If not, I'd be willing to implement this feature. Dustin ___ Development mailing list

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wed, Oct 14, 2015 at 06:37:19AM +, Knoll Lars wrote: > Agree here as well. We can’t make QString utf-8 backed without breaking > way too much code. I also don’t see the need for it. The native encoding > on Windows and Mac (Cocoa) is utf-16 as well, on Linux it’s utf-8. So no > matter which

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 22:56:15 André Pönitz wrote: > > I think there’s actually quite a few of those. In addition, it might be > > tricky to use QStringView in signals and slots. > > One could try to be clever and go through an intermediate QString > object at least in queued connections.

Re: [Development] QTime microsecond support

On Wednesday 14 October 2015 14:22:13 Dustin Mitchell wrote: > Hello, > > Are there plans to support microseconds in the QTime class? I need to parse > timestamps from a text file and it has microsecond resolution. If not, I'd > be willing to implement this feature. You'll have to wait for Qt 6.

Re: [Development] QTime microsecond support

On Wednesday 14. October 2015 23:10:56 Olivier Goffart wrote: > On Wednesday 14. October 2015 13:53:03 Thiago Macieira wrote: > > On Wednesday 14 October 2015 14:22:13 Dustin Mitchell wrote: > > > Hello, > > > > > > Are there plans to support microseconds in the QTime class? I need to > > > parse

Re: [Development] QTime microsecond support

On Wednesday 14 October 2015 23:10:56 Olivier Goffart wrote: > On Wednesday 14. October 2015 13:53:03 Thiago Macieira wrote: > > On Wednesday 14 October 2015 14:22:13 Dustin Mitchell wrote: > > > Hello, > > > > > > Are there plans to support microseconds in the QTime class? I need to > > > parse

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 21:51:23 Bubke Marco wrote: > On October 14, 2015 23:10:26 Thiago Macieira wrote: > > Do it on your own. You just said that ICU has the function you want, so > > use > > it. > > So Qt is always shipping with ICU? It can be disabled on

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 14, 2015 22:13:11 Thiago Macieira wrote: > On Wednesday 14 October 2015 17:55:34 Bubke Marco wrote: >> Think about a local aware compare which is called very very often. You don't >> want malloc in between. In in most cases you get an const char* or const >>

Re: [Development] QTime microsecond support

On Wednesday 14. October 2015 13:53:03 Thiago Macieira wrote: > On Wednesday 14 October 2015 14:22:13 Dustin Mitchell wrote: > > Hello, > > > > Are there plans to support microseconds in the QTime class? I need to > > parse > > timestamps from a text file and it has microsecond resolution. If

Re: [Development] QTime microsecond support

On Wednesday 14 October 2015 16:21:10 Dustin Mitchell wrote: > I see what you mean about a lot of things assuming mds within QTime > contains milliseconds. Would changing QTime to support microseconds be too > much of an invasive change to include before Qt 6? Yes. When I said "impossible", I

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 20:52:12 Bubke Marco wrote: > On October 14, 2015 22:13:11 Thiago Macieira wrote: > > On Wednesday 14 October 2015 17:55:34 Bubke Marco wrote: > >> Think about a local aware compare which is called very very often. You > >> don't want

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 14, 2015 23:10:26 Thiago Macieira wrote: > On Wednesday 14 October 2015 20:52:12 Bubke Marco wrote: >> On October 14, 2015 22:13:11 Thiago Macieira > wrote: >> And I don't want an utf 8 baked >> QString. For my use cases implicit

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wed, Oct 14, 2015 at 11:15:55AM +, Knoll Lars wrote: > >That leaves classes which simply store the string. You cited QUrl. I > >don't see > >a problem providing QString overloads for these, esp. considering that > >we're > >starting out with an all-QString API here. Then again, once we

Re: [Development] QTime microsecond support

I see what you mean about a lot of things assuming mds within QTime contains milliseconds. Would changing QTime to support microseconds be too much of an invasive change to include before Qt 6? Dustin On Wed, Oct 14, 2015 at 3:14 PM, Thiago Macieira wrote: > On

Re: [Development] QTime microsecond support

That's unfortunate. I guess I'll have to use another library in the interim. Is there a target date for Qt 6 yet? An initial Google search didn't yield many results. Dustin On Wed, Oct 14, 2015 at 4:28 PM, Thiago Macieira wrote: > On Wednesday 14 October 2015

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Tuesday 13 October 2015, Marc Mutz wrote: > Hi, > > After looking quite a bit into the current state of string handling in Qt > for my QtWS talk last week, I have become frustrated by the state of > string handling in Qt. > > We have such powerful tools for string handling (QStringRef, >

[Development] Possible bug in touch event coordinates in QtWebEngine when using pixelDeviceRatio

Hello folks, I am currently working towards using QtWebEngine for our project (LuneOS), and I stumbled upon an issue. I am using the experimental devicePixelRatio property in the QML WebEngineView component, so that our html page is displayed nicely on mobile device with high DPI. However, I

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Thursday 15 October 2015 00:27:14 Thiago Macieira wrote: > Way too much code would break if we did that because we allow people access > to the data pointer in QString and to iterate directly > (std::{,w,u16}string don't allow that, which makes parsing them actually a > lot more cumbersome).

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Hi Andre, On Wednesday 14 October 2015 22:37:01 André Pönitz wrote: > That's why I'd like to propose the following: > > Since experiments within Qt proper are difficult due to the BC > and SC guarantees we give and the practical impossibility to un-do > additions we should simply not do it

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wed, Oct 14, 2015 at 11:15:55AM +, Knoll Lars wrote: > >> >> A: Once QString is backed by UTF-8, [...] > > It’s worthwhile discussing, but any such change would have huge > implications on our QString API. > indeed. > In any case, it’s nothing we can do in Qt 5. > i don't think this is

Re: [Development] New Qt Modules

On 10/13/2015 12:01 PM, Oswald Buddenhagen wrote: > On Tue, Oct 13, 2015 at 08:53:21AM +, Hausmann Simon wrote: >> I think code that isn't specific to the automotive industry such as as >> the dbus integration should be integrated into existing modules unless >> there is a good reason

Re: [Development] QTime microsecond support

On Thursday 15 October 2015 02:09:07 Aleix Pol wrote: > Maybe you could look into forking QTime with the microseconds changes? > That could be reasonable even within Qt. Indeed, that would. We'll have to have a long discussion on what to name the class, though... QTimeExtended? QExtendedTime?

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Thursday 15 October 2015 02:22:50 Marc Mutz wrote: > On Thursday 15 October 2015 00:27:14 Thiago Macieira wrote: > > Way too much code would break if we did that because we allow people > > access > > to the data pointer in QString and to iterate directly > > (std::{,w,u16}string don't allow

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Marc Mutz > I'm not optimising. I'm decoupling the concept of a "QString" from the owning > implementation "QString", so that we don't need to either convert from/to > QString quite so often or you can use "foreign types" > (std::basic_string, char16_t[], ...) in lieu of

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 2015-10-14 07:15, Knoll Lars wrote: > In addition, it might be tricky to use QStringView in signals and > slots. As I previously stated, I'm pretty sure you *CAN'T* use QStringView to call slots, except for direct call. In any other case, you risk the backing data being modified or, worse,

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 2015-10-14 06:16, Marc Mutz wrote: > First, afaiu from what Thiago mentions in reviews, Q6String will have SSO > (small-string-optimisation) which makes many short strings expensive to copy > (if you think that copying 24 bytes is slower than upping an atomic int > through an indirection) or

Re: [Development] QTime microsecond support

On Wednesday 14 October 2015 16:36:51 Dustin Mitchell wrote: > That's unfortunate. I guess I'll have to use another library in the > interim. Is there a target date for Qt 6 yet? An initial Google search > didn't yield many results. There is no date, at all. Considering 5.6 is our first Long Term

Re: [Development] QTime microsecond support

On Thu, Oct 15, 2015 at 12:36 AM, Dustin Mitchell wrote: > That's unfortunate. I guess I'll have to use another library in the interim. > Is there a target date for Qt 6 yet? An initial Google search didn't yield > many results. > > Dustin > > On Wed, Oct 14, 2015 at 4:28 PM,

Re: [Development] QTime microsecond support

On Thursday 15 October 2015 06:03:40 Thiago Macieira wrote: > We'll have to have a long discussion on what to name the class, though... > QTimeExtended? QExtendedTime? QTimeV2? QMicroTime? QTimeSpan? std::chrono::{duration,time_point,clock}. In Qt6, a compat-only QTime will be a thin wrapper