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
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
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,
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} ב"
> > ;
> >
>
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
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
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:
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
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
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
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
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
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
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
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:
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
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
> 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
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
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-
> 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
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
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
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
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
25 matches
Mail list logo