Re: [Development] Introducing discussion about QStringFormatter

2017-08-17 Thread Mårten Nordheim
On 15.08.2017 18:05, Matthew Woehlke wrote: Possibly there could be a qFormat (or even qFormatString) free function providing extra convenience and abbreviation for the most common use case? (This could be instead of the static ::format function...) qFormatString is even less typing than

Re: [Development] Introducing discussion about QStringFormatter

2017-08-17 Thread Mårten Nordheim
On 14.08.2017 18:20, Thiago Macieira wrote: I had the same problem, but I guess we can safely assume that anyone writing RTL text in their source code knows what they're doing and are used to the text direction changing (or they'll report bugs if the behaviour is wrong). My question is whether

Re: [Development] Introducing discussion about QStringFormatter

2017-08-15 Thread Matthew Woehlke
On 2017-08-10 22:20, Thiago Macieira wrote: > On quinta-feira, 10 de agosto de 2017 17:53:39 PDT Sze Howe Koh wrote: >> On 10 August 2017 at 20:41, Mårten Nordheim wrote: >> IMHO, "QFormat" isn't a suitable name. First, this class itself does >> not describe a format,

Re: [Development] Introducing discussion about QStringFormatter

2017-08-14 Thread Thiago Macieira
On Monday, 14 August 2017 07:12:30 PDT Mårten Nordheim wrote: > > Has this ever been validated with people using RTL languages? The < and > > > > > symbols switch directions when used in RTL. For example: > > const char *fmt = > > > > "א {<10} ב" > > ; > > >

Re: [Development] Introducing discussion about QStringFormatter

2017-08-14 Thread Mårten Nordheim
Has this ever been validated with people using RTL languages? The < and > symbols switch directions when used in RTL. For example: const char *fmt = "א {<10} ב" ; Can you tell from the pasted text which direction this will justify? I intentionally put the

Re: [Development] Introducing discussion about QStringFormatter

2017-08-11 Thread Thiago Macieira
On sexta-feira, 11 de agosto de 2017 02:01:11 PDT Mårten Nordheim wrote: > Replacement format > > >>> - > >>> > >>> The replacement options now have formatting features matching > >>> QString::arg. The current options (open to change) are: > >>> > >>> - `L` for localization (localize

Re: [Development] Introducing discussion about QStringFormatter

2017-08-11 Thread Mårten Nordheim
On 11.08.2017 04:20, Thiago Macieira wrote: On quinta-feira, 10 de agosto de 2017 17:53:39 PDT Sze Howe Koh wrote: On 10 August 2017 at 20:41, Mårten Nordheim wrote: IMHO, "QFormat" isn't a suitable name. First, this class itself does not describe a format, unlike:

Re: [Development] Introducing discussion about QStringFormatter

2017-08-10 Thread Thiago Macieira
On quinta-feira, 10 de agosto de 2017 17:53:39 PDT Sze Howe Koh wrote: > On 10 August 2017 at 20:41, Mårten Nordheim wrote: > IMHO, "QFormat" isn't a suitable name. First, this class itself does > not describe a format, unlike: [cut] > For these reasons, I'd personally

Re: [Development] Introducing discussion about QStringFormatter

2017-08-10 Thread Sze Howe Koh
Hello, On 10 August 2017 at 20:41, Mårten Nordheim wrote: > > Hello, I'm back with round 2 of QStringFormatter > = > > The WIP is still located over here: > https://codereview.qt-project.org/#/c/192873/ > > Name > - > > I think it would be nice to change the

Re: [Development] Introducing discussion about QStringFormatter

2017-08-10 Thread Mårten Nordheim
Hello, I'm back with round 2 of QStringFormatter = The WIP is still located over here: https://codereview.qt-project.org/#/c/192873/ Name - I think it would be nice to change the class' name as typing QStringFormatter repeatedly is fairly cumbersome. One suggestion was QFormat (unless

Re: [Development] Introducing discussion about QStringFormatter

2017-05-18 Thread Thiago Macieira
On Thursday, 18 May 2017 02:57:43 PDT Mårten Nordheim wrote: > But to clarify, in your scenario > "{}{}" % ("a", "b") > would be "ab", correct? That's what I would expect, yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

Re: [Development] Introducing discussion about QStringFormatter

2017-05-18 Thread Thiago Macieira
On Thursday, 18 May 2017 02:39:36 PDT Mårten Nordheim wrote: > > Please consider, in terms of Qt API design (ease of use, surprise factor, > > etc.) just what the following should do: > > > > QStringFormatter("%1 is {1}").arg("foo").subs("bar") > > Hm, hadn't thought that far ahead, thanks. I

Re: [Development] Introducing discussion about QStringFormatter

2017-05-18 Thread Mårten Nordheim
On 16.05.2017 19:14, Thiago Macieira wrote: On {}{}: I think that's an acceptable shorthand, just like we have "%1 is %1" today. A bracket without any digits has higher replacement precedence than {0}: "The {0} brown {} jumped over the {2} {3}" % ("fox", "quick", "dog", "lazy") {} gets

Re: [Development] Introducing discussion about QStringFormatter

2017-05-18 Thread Mårten Nordheim
On 16.05.2017 19:23, Thiago Macieira wrote: On segunda-feira, 15 de maio de 2017 05:49:19 PDT Mårten Nordheim wrote: - Note: To print a curly brace they have to be doubled (same as in all of the above) ( "{{", "}}" ) Why do we need a double closing curly

Re: [Development] Introducing discussion about QStringFormatter

2017-05-16 Thread Thiago Macieira
On segunda-feira, 15 de maio de 2017 05:49:19 PDT Mårten Nordheim wrote: >- Note: To print a curly brace they have to be doubled (same >as in all of the above) ( "{{", "}}" ) Why do we need a double closing curly brace? This is not a valid sequence:

Re: [Development] Introducing discussion about QStringFormatter

2017-05-16 Thread Robin Burchell
On Tue, May 16, 2017, at 07:14 PM, Thiago Macieira wrote: > I'd prefer we kept the % syntax which we already have, but from the > discussion, it looks like it won't work. We need a syntax that has a > clear > open and close so that more options can be placed inside the placeholder. A potential

Re: [Development] Introducing discussion about QStringFormatter

2017-05-16 Thread Thiago Macieira
On terça-feira, 16 de maio de 2017 06:50:18 PDT Jason H wrote: > I also wonder about the SQL bound parameter interface? That formatting is a > mash of :? or :name or something else (":1"?). I think for consistency, > that should be able to use whatever the rest of the toolkit does too. Choose one

Re: [Development] Introducing discussion about QStringFormatter

2017-05-16 Thread Shawn Rutledge
> On 15 May 2017, at 15:16, Marc Mutz wrote: > > Open For Extension - Users can add formatting for their own types (like > QStringBuilder allows, but using documented API). QDateTime, etc support to > be added as examples. We’ve been writing QDebug operator<<(QDebug

Re: [Development] Introducing discussion about QStringFormatter

2017-05-16 Thread Robin Burchell
On Mon, May 15, 2017, at 02:49 PM, Mårten Nordheim wrote: > 3. What are its soft requirements? One very low priority item floating around on my wishlist would be formatting for QByteArray as well, though this is of course a bit of a task. But it would be useful for cases when you want to avoid

Re: [Development] Introducing discussion about QStringFormatter

2017-05-16 Thread Jason H
l". > Sent: Tuesday, May 16, 2017 at 4:12 AM > From: "Edward Welbourne" <edward.welbou...@qt.io> > To: "Jason H" <jh...@gmx.com>, "Mårten Nordheim" <marten.nordh...@qt.io> > Cc: "development@qt-project.org" <development@qt-

Re: [Development] Introducing discussion about QStringFormatter

2017-05-16 Thread Eike Ziller
> On May 16, 2017, at 10:12 AM, Edward Welbourne wrote: > > Jason H (15 May 2017 23:52): >> Having worked with Python's format(), I much prefer the alterative {} >> syntax, where {} defers to the next paramter. >> '{}{}{}'.format('a', 'b', 'c) == 'abc' >> Which makes

Re: [Development] Introducing discussion about QStringFormatter

2017-05-16 Thread Edward Welbourne
Jason H (15 May 2017 23:52): > Having worked with Python's format(), I much prefer the alterative {} > syntax, where {} defers to the next paramter. > '{}{}{}'.format('a', 'b', 'c) == 'abc' > Which makes maintence much easier, However, it can be problematic for translation; some languages shall

Re: [Development] Introducing discussion about QStringFormatter

2017-05-15 Thread Jason H
to see QML get fomr formatting love as well.   Sent: Monday, May 15, 2017 at 8:49 AM From: "Mårten Nordheim" <marten.nordh...@qt.io> To: "development@qt-project.org" <development@qt-project.org> Subject: [Development] Introducing discussion about QStringFormat

Re: [Development] Introducing discussion about QStringFormatter

2017-05-15 Thread Marc Mutz
On Monday 15 May 2017 14:49:19 Mårten Nordheim wrote: > 1. Why do we [not] want QStringFormatter in the library? con: already have enough formatters in Qt, better work on those than introducing something else _again_. pro: have too many formatters in Qt, add one that can encompass and replace

[Development] Introducing discussion about QStringFormatter

2017-05-15 Thread Mårten Nordheim
This discussion's about a proposed 'QStringFormatter' class (for which I put up an early WIP for here: https://codereview.qt-project.org/#/c/192873/ ) QStringFormatter is currently intended as a class to format strings and replace placeholders, like QString::arg does. But without the issues