On Fri, Aug 13, 2021 at 07:17:16AM +, Jani Heikkinen wrote:
> Hi!
>
> We are planning to simplify our packaging and releasing scripts and one thing
> which
> would simplify our scripts is removal of version tag parsing for src (and
> example)
> packages. So the question is if we can remove
On Fri, May 21, 2021 at 07:04:01AM +, Eike Ziller wrote:
> > I hear will be forgotten a few days later. If I hear something important, I
> > might
> > take a note, in an explicit, extra step. Under no circumstances I will be
> > able to
> > "remember" something someone said in a room I
On Thu, May 20, 2021 at 11:59:31AM +, Andy Nichols wrote:
> >> The chat channels are fragmented these days. There’s the Qt discord
> >> channels,
> >> QtMob on Slack, Qt and Advanced C++ on Telegram.
>
> > Are any of these channels endorsed by the Qt project? The IRC channels
> > are,
On Wed, May 19, 2021 at 08:34:50PM +0200, Giuseppe D'Angelo via Development
wrote:
> On 19/05/2021 19:31, André Pönitz wrote:
> >
> > And now since we are on it: Can someone please remove the +r from #qt ?
> > All other #qt-* channels at FreeNode are fine without.
&g
On Wed, May 19, 2021 at 05:03:24PM +0200, Ulf Hermann wrote:
> > Rather than just move to another IRC server, we should really take
> > this as an opportunity to move to another chat service as the
> > official Qt Project chat. IRC has a terrible user experience and is
> > not at all accessible
On Wed, May 19, 2021 at 02:37:26PM +, Andy Nichols wrote:
> Hello,
>
> Rather than just move to another IRC server, we should really take
> this as an opportunity to move to another chat service as the official
> Qt Project chat.
>
> IRC has a terrible user experience and is not at all
> Ville Voutilainen
> On Fri, 5 Mar 2021 at 14:26, Giuseppe D'Angelo via Development
> wrote:
> >
> > Il 05/03/21 12:08, Tor Arne Vestbø ha scritto:
> > > This seems like a bug though? From an API point of view, I’d expect this
> > > simple assignment to JustWorkTM, without requiring syntactic
On Tue, Feb 16, 2021 at 04:35:25PM +0200, Ville Voutilainen wrote:
> On Tue, 16 Feb 2021 at 15:35, Kai Köhne wrote:
> > And again, this is not something limited to Qt. Last time I checked,
> > the executable to run Python 3 on Windows is python.exe, not
> > python3.exe. On Debian at least it's
On Wed, Jan 13, 2021 at 12:48:45PM -0800, Thiago Macieira wrote:
> On Wednesday, 13 January 2021 10:17:02 PST André Pönitz wrote:
> > I have a product that depends on qtbase, qtdeclarative and qttool, and
> > qtdeclarative and qttools refer to different and incompatible version
On Wed, Jan 13, 2021 at 01:37:21PM +, Volker Hilsheimer wrote:
> [...]
> The workflow with such a setup would not be fundamentally different
> from today. You clone one thing (build system repo instead of
> qt5.git), you run a script and tell the script what you want to work
> on to get all
On Fri, Sep 18, 2020 at 11:56:38AM -0700, Thiago Macieira wrote:
> On Friday, 18 September 2020 09:38:12 PDT Ville Voutilainen wrote:
> > > We should use one of the types from [1]. Yes, it's C++20; we can
> > > make our internal API return an integer that is convertible to those types
> > > in the
On Wed, Sep 02, 2020 at 09:15:37AM +0200, Mathias Hasselmann wrote:
> I'd rather say that cast is entirely ugly. Seems like a perfect example or
> code smell: Something is fundamentally wrong they way qsizetype is defined.
Funnily enough the same can be said for the casts that are now necessary
On Wed, Sep 02, 2020 at 09:37:49PM +0200, Giuseppe D'Angelo via Development
wrote:
> On 02/09/2020 21:18, Andrei Golubev wrote:
> > Also not sure whether it is an implementation detail or the behavior
> > that should always be anticipated.
>
> People build performance sensitive code assuming the
On Mon, Aug 24, 2020 at 09:46:43AM +0200, Mathias Hasselmann wrote:
>C++ also has a solution for that problem: [1]
>
> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
AAA is a non-solution from the ivory tower.
It's a pain for human reviewers and tools
On Mon, Aug 24, 2020 at 09:26:54AM +0200, Giuseppe D'Angelo via Development
wrote:
> On 23/08/2020 16:06, Marcel Krems wrote:
> > If they keep using int there could be a lot of warnings like this one:
> > warning: implicit conversion loses integer precision: 'qsizetype' (aka
> > 'long long') to
On Wed, Jul 22, 2020 at 10:24:21AM -0700, Thiago Macieira wrote:
> On Wednesday, 22 July 2020 09:55:31 PDT André Pönitz wrote:
> > How often do we think people are actively taking advantage of Qt's BC
> > promise (and how often do we hold this promise, and how often is this
> &
On Wed, Jul 22, 2020 at 10:27:14AM +, Lars Knoll wrote:
> > On 22 Jul 2020, at 11:38, Shawn Rutledge wrote:
> >
> >
> >> On 2020 Jul 16, at 11:19, Ulf Hermann wrote:
> >>
> >> Data bindings are a cornerstone of most modern UI frameworks, and Qt is
> >> actually late to the game. If we
On Thu, Jul 16, 2020 at 11:08:40AM +, Edward Welbourne wrote:
> Giuseppe D'Angelo (16 July 2020 12:58) requested:
> > Could anyone please illustrate with some code snippets how to achieve
> > this, in practice, in a number of use cases? E.g. client code (non
> > pimpled QObject subclass), (Qt)
On Sun, Jun 21, 2020 at 11:22:58AM +, Lars Knoll wrote:
> We didn’t want it in earlier versions of Qt for mainly two reasons. Early
> implementations had quite an overhead on library size, and dynamic_cast didn’t
> work reliable between DLL boundaries on Windows. Both problems have gone away
>
On Tue, Jun 09, 2020 at 08:06:57AM +, Alexandru Croitor wrote:
> > On 9. Jun 2020, at 04:32, André Pönitz wrote:
> >
> > On Mon, Jun 08, 2020 at 01:43:20PM +, Alexandru Croitor wrote:
> >> [...]
> >> The CMake ports are built in Coin with the most
On Wed, Apr 29, 2020 at 01:41:46AM +0200, Giuseppe D'Angelo via Development
wrote:
> Il 28/04/20 21:45, Matthew Woehlke ha scritto:
> > > * QList gets adapted so that its internal array allocates 3 *
> > > sizeof(void*) per element, so that e.g. Q6StringList won't require a
> > > per-item
On Thu, May 14, 2020 at 11:46:29AM +0200, Marc Mutz via Development wrote:
> > Please stop with this crusade of yours to end all CoW, get rid of
> > QList, etc. It is misguided and harmful to the ecosystem at large.
>
> You are entitled to your opinions just as I am. The difference is that I put
On Tue, May 12, 2020 at 02:09:21PM -0700, Thiago Macieira wrote:
> On Tuesday, 12 May 2020 10:48:24 PDT Giuseppe D'Angelo via Development wrote:
> > What do you do? Adding a QStringView overload will make calls ambiguous,
> > removing the QString one will be an ABI break. We need an established
>
On Tue, Apr 28, 2020 at 12:25:32AM +0200, Jean-Michaël Celerier wrote:
>> As starters, there are 85 occurences of QList::takeFirst() in Qt
>> Creator source code. Replacing these with QVector replaces a O(1)
>> operation with an O(n) operation.
>
>Apologies if I'm wrong, but isn't
On Mon, Apr 27, 2020 at 11:13:26AM -0400, Matthew Woehlke wrote:
> On 25/04/2020 10.49, André Pönitz wrote:
> > We all know the story that began with
> >
> > "We knew for a long time that QList is not a good default
> > container, despite what the d
Spam detection software, running on the system "mx.qt-project.org",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
On Fri, Apr 24, 2020 at 09:33:49AM +0200, Christian Ehrlicher wrote:
> 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.
> >
On Thu, Apr 23, 2020 at 04:45:02PM +0200, Giuseppe D'Angelo via Development
wrote:
> On 4/23/20 1:20 PM, Edward Welbourne wrote:
> > So how much harm does it really cause, to keep both names; and use
> > whichever feels like the more natural description of the value one is
> > returning ?
>
> I
On Thu, Apr 23, 2020 at 05:04:27PM +0200, Julius Bullinger wrote:
> On 23.04.2020 16:45, Giuseppe D'Angelo via Development wrote:
> > == Naming of functions and types if QList = QVector ==
> >
> > We have QStringList, QVariantList and friends, which are aliases /
> > subclasses of QList and so
On Thu, Apr 23, 2020 at 12:25:33PM +, Vitaly Fanaskov wrote:
>I think we should completely remove QList in Qt6. It was planned
>before, as far as I remember. The main reason is to be consistent with
>STL wording and do not violate POLA too much.
>
>I read the entire
On Thu, Apr 23, 2020 at 12:48:45PM +0200, Elvis Stansvik wrote:
> Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs :
> >
> > That depends on the number of the functions affected, and how commonly those
> > are used. If we are talking about just a few virtual functions here and
> > there
> >
On Thu, Apr 23, 2020 at 12:17:38PM +0200, Daniel Engelke wrote:
>> You'd need also adapt some variable and function names,
>> comments and documentation are silently broken.
>
>I don't really see it, unless you name all variables like qListMyList.
>
>As for comments it's not like
On Thu, Apr 23, 2020 at 12:30:32PM +0300, Ville Voutilainen wrote:
> On Thu, 23 Apr 2020 at 12:25, Philippe wrote:
> >
> > Almost all the time I second your positions, but not this time ;)
> >
> > QList is historically a cause of ambiguity, and Qt6 is the chance to get
> > rid of that.
>
>
On Thu, Apr 23, 2020 at 10:02:04AM +0200, André Pönitz wrote:
> On Thu, Apr 23, 2020 at 07:43:33AM +, Simon Hausmann wrote:
> >Hi,
> >
> >In dev we've had QVector being an alias for QList for a while now. For
> >the 6.0 release this particular topic (
On Thu, Apr 23, 2020 at 10:52:07AM +0200, Daniel Engelke wrote:
>I don't see a lot of work in string replacing QList with QVector and
>QStringList with whatever it would be, as long as the API is
>compatible.
A proper replacing is not done by replacing one type by another.
You'd need
On Thu, Apr 23, 2020 at 10:06:07AM +0200, Albert Astals Cid via Development
wrote:
> El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> > Hi,
> >
> > In dev we've had QVector being an alias for QList for a while now. For the
> > 6.0 release this particular topic
On Thu, Apr 23, 2020 at 07:43:33AM +, Simon Hausmann wrote:
>Hi,
>
>In dev we've had QVector being an alias for QList for a while now. For
>the 6.0 release this particular topic (QList/QVector) suggests two
>goals (among others):
>
>(1) Use the same type throughout
On Fri, Mar 13, 2020 at 07:00:46PM +0100, enston...@gmail.com wrote:
>Hi,
>
>I forwarded my message to the security team on Monday
>([1]secur...@qt-project.org).
>I didn't get any answer except this:
> Your mail to 'Security' with the subject
>
> Fwd: Re: [Development]
On Fri, Mar 06, 2020 at 11:59:32AM +, Simon Hausmann wrote:
>Hi,
>
>I think it would be great to have a result type in the Qt API and use
>that, instead of C++ exceptions. In theory we could use std::variant,
>but I think the API inconvenient for the use-case of a result. That
On Fri, Feb 21, 2020 at 11:03:19PM +0200, Ville Voutilainen wrote:
> On Fri, 21 Feb 2020 at 22:11, André Pönitz wrote:
> >
> > On Fri, Feb 21, 2020 at 04:02:04PM +0200, Ville Voutilainen wrote:
> > > > I, for one, definitely want to see whe
On Fri, Feb 21, 2020 at 04:02:04PM +0200, Ville Voutilainen wrote:
> > I, for one, definitely want to see whether I am emitting a signal or not.
>
> Right; the claims that you can ignore signal emits when looking at a
> piece of code or expect that they
> don't affect the current scope are
On Fri, Feb 21, 2020 at 02:41:35PM +0200, Ville Voutilainen wrote:
> On Fri, 21 Feb 2020 at 14:30, Mitch Curtis wrote:
>
> > > > without any annotation is not what we want. We'd miss vital
> > > > information
> > > and reduce readability. Can you please explain what that vital
> > > information
On Fri, Feb 21, 2020 at 08:40:23AM +, Alex Blasche wrote:
> > -Original Message- From: Kai Köhne
>
> > Another alternative is to actually use C++ attributes for this:
> >
> > [[qt::emit]] somethingChanged();
>
> I think a fallback to
>
> somethingChanged()
>
> without any
On Wed, Feb 19, 2020 at 06:26:56PM +0200, Konstantin Ritt wrote:
> Should we ever try to work around issues caused by broken CPUs?
Yes.
Because "CPU is broken" one way or the other is rather the common
case. Declining to work as best as reasonably feasible in this
situation might as well end up
On Wed, Feb 19, 2020 at 10:43:17AM +, Volker Hilsheimer wrote:
> Even when doing development (as opposed to the pointy-haired work), I
> benefit from having tools that help me to maintain a work-in-progress
> limit, that allow me to see what state the work someone else is doing
> is in
On Wed, Feb 19, 2020 at 09:45:48AM +, Edward Welbourne wrote:
> On Tue, Feb 18, 2020 at 01:11:29PM +1000, Lorn Potter wrote:
> >> Stepping through the interim steps is not a requirement, so it is not that
> >> much difference to go from Reported->In Progress to Reported->In Review,
> >>
On Tue, Feb 18, 2020 at 01:11:29PM +1000, Lorn Potter wrote:
> On 18/2/20 6:03 AM, Thiago Macieira wrote:
> > I'm with Alexandru here: all ideas to have more states in JIRA start with a
> > good intentions, but eventually people stop using them and just transition
> > through all stages in one go
On Mon, Feb 17, 2020 at 09:13:17AM +, Edward Welbourne wrote:
> When my team is planning sprints, our scrum master wants to know what
> tasks I'll be working on, and what counts as "Done" for each of them.
> Having a separate state for "In Review", distinct from "In Progress",
> would let us
On Thu, Feb 13, 2020 at 10:01:02AM +, Maurice Kalinowski wrote:
> > From: Development On Behalf Of
> > André Pönitz Sent: Wednesday, February 12, 2020 8:00 PM To: Allan
> > Sandfeld Jensen Cc: development@qt-project.org
> > Subject: Re: [Development] The future of
On Thu, Feb 13, 2020 at 09:42:23AM +, Karsten Heimrich wrote:
> -Original Message-
> >From: André Pönitz Sent: Mittwoch, 12. Februar
> >2020 19:38 Uhr To: Vitaly Fanaskov Cc:
> >Karsten Heimrich ; development@qt-project.org
> >Subject: Re: [Development] T
> On Mon, Feb 03, 2020 at 11:53:57PM +, Scott Bloom wrote:
> > From: Development [mailto:development-boun...@qt-project.org] On
> > Behalf Of André Pönitz
> > [...]
> > An actual "need" for a unique pointer is typically a sign that
> > things a
On Wed, Feb 12, 2020 at 05:08:33PM +0100, Allan Sandfeld Jensen wrote:
> > Allowing _both_ I have not seen actively endorsed by anyone,
> > this only makes a messy incosnsistent API.
>
> I would allow both. It is the only way to remain source
> compatible, while making it possible for those that
On Wed, Feb 12, 2020 at 11:13:17AM +, Vitaly Fanaskov wrote:
> >> We should also move Qt smart pointers to Qt5Compat module. The
> >> destiny of QPointer is not well defined so far.
> >
> > This was not part of the research and should probably discussed
> > separately.
>
> I agree. But if we
On Tue, Feb 11, 2020 at 03:15:11PM +, Vitaly Fanaskov wrote:
> I want to summarize intermediate results of the discussion and return it
> back to the track.
>
>
> Subject: using smart pointers in the API.
> Good idea. Better to use than not because of automatic lifetime
> management,
On Thu, Feb 06, 2020 at 01:51:17PM +, Alex Blasche wrote:
>
> > -Original Message- From: Development
> > On Behalf Of Thiago Macieira
> >
> > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> > > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
> > >
> > > wrote:
On Tue, Feb 04, 2020 at 10:10:08PM +0200, Ville Voutilainen wrote:
> On Tue, 4 Feb 2020 at 21:31, André Pönitz wrote:
> > Seriously, *double deletion*? In real, proper Qt-style code?
>
> Yes, seriously, because allocated objects are stored in RAII handles
A "Qt style" &
On Tue, Feb 04, 2020 at 07:42:22AM +0100, Giuseppe D'Angelo wrote:
> Il 03/02/20 23:55, André Pönitz ha scritto:
> > On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote:
> > > Il 03/02/20 20:38, André Pönitz ha scritto:
> > > > Directly affected are fo
On Tue, Feb 04, 2020 at 06:49:50AM +0100, Giuseppe D'Angelo wrote:
> Il 04/02/20 00:49, André Pönitz ha scritto:
> > > I've asked "what's wrong with the C++ smart pointers" a dozen times and
> > > never received a satisfactory answer.
> > Did you? I am - t
On Tue, Feb 04, 2020 at 07:17:13PM +0200, Ville Voutilainen wrote:
> On Tue, 4 Feb 2020 at 18:48, Volker Hilsheimer
> wrote:
> > >>> But that just means that QBoxLayout::addWidget(std::unique_ptr<>) has to
> > >>> behave imho saner in that edge case and actually delete the widgets that
> > >>>
On Tue, Feb 04, 2020 at 03:52:34PM +, Vitaly Fanaskov wrote:
>
> I also don't think that this is something we should worry about when
> discussing adding smart pointers.
I think I've still not understood what "adding smart pointers" means when you
use
the term. Right now my impression is
On Mon, Feb 03, 2020 at 10:25:40PM +0100, Giuseppe D'Angelo via Development
wrote:
> I've asked "what's wrong with the C++ smart pointers" a dozen times and
> never received a satisfactory answer.
Did you? I am - to some degree truly - afraid I didn't notice.
Answer would have been easy: They
On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote:
> Il 03/02/20 20:38, André Pönitz ha scritto:
> > Directly affected are for instance functions operating on full containers in
> >
> >https://doc.qt.io/qt-5/qtalgorithms-obsolete.html
>
> Just
On Sun, Feb 02, 2020 at 11:32:02PM +0100, Giuseppe D'Angelo wrote:
> On 02/02/2020 22:45, André Pönitz wrote:
> > > This is a logical fallacy; "I don't need it, noone else does".
> > But this is the argument the de-Qt-ers use when it comes to Qt convenience
> &
On Sun, Feb 02, 2020 at 07:55:09PM +0100, Giuseppe D'Angelo via Development
wrote:
> On 02/02/2020 17:38, Alberto Mardegan wrote:
> > On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote:
> > > Il 01/02/20 12:37, Alberto Mardegan ha scritto:
> > > > Do we need to have such a counterpart? In
On Fri, Jan 31, 2020 at 03:27:29PM +, Vitaly Fanaskov wrote:
> Not abandoning, I think, but re-implementing properly. Raw pointers
> cause some certain problems here and changing them to something more
> smart would be nice. But it doesn't mean that we should get rid of
> parent-child model
On Fri, Jan 31, 2020 at 10:07:52AM +, Vitaly Fanaskov wrote:
> Another thing to discuss is whether we should use raw pointers in the
> API at all or not. There are a few options again:
>
> 1) Yes
>
> 2) No. Use “modern” approaches instead (pass mandatory dependencies by
> either reference
On Fri, Dec 20, 2019 at 02:47:06PM +0100, Giuseppe D'Angelo via Development
wrote:
> Il 20/12/19 12:20, Philippe ha scritto:
> > std::unordered_map is before all an interface and the implemenation varies
> > according to the library supplier.
> > And this, potentially much more eg. than
On Thu, Dec 05, 2019 at 06:12:53PM +0100, Giuseppe D'Angelo via Development
wrote:
> Il 04/12/19 12:56, Volker Hilsheimer ha scritto:
> > IIRC, then I added that in the early Qt 2 days, anticipating that with
> > Qt/Embedded we might see our widgets landing on touch screens “any moment
> > now”.
On Sun, Nov 24, 2019 at 09:48:46PM -0800, Thiago Macieira wrote:
> On Sunday, 24 November 2019 00:50:14 PST André Pönitz wrote:
> > Regarding the risk of "introduce subtle bugs by truncating sizes": That risk
> > _is_ there in general for some of the pr
On Sun, Nov 24, 2019 at 12:31:32PM +0100, Konrad Rosenbaum wrote:
> I'd rather have the compiler tell me that I need to change my code than hide
> it from me. Warnings are there for a good reason.
["Some"...]
> The only way to do this with this proposal is to make count() deprecated from
> the
On Sun, Nov 24, 2019 at 11:30:29AM +0100, Giuseppe D'Angelo via Development
wrote:
> Il 24/11/19 10:44, Uwe Rathmann ha scritto:
> > I fully agree with André - having 2 different APIs makes a lot of sense
> > to me. But instead of using count/size I would use something like
> > countU/sizeU. like
On Sat, Nov 23, 2019 at 11:26:02PM +0100, Thiago Macieira wrote:
> On Saturday, 23 November 2019 13:55:52 CET André Pönitz wrote:
> > Also, replacing size() by count() would be easy to do in e.g. Creator
> > (effectively a single global renaming of size() to count() and discarding
On Sat, Nov 23, 2019 at 12:48:12PM +0100, Thiago Macieira wrote:
> On Saturday, 23 November 2019 09:47:23 CET André Pönitz wrote:
> > So let's make this a real proposal: Should we have
> >
> >qsizetype QContainer::size()
> >int QContainer::count() const
>
On Fri, Nov 22, 2019 at 08:01:30PM +0100, Giuseppe D'Angelo via Development
wrote:
> Il 22/11/19 18:49, Thiago Macieira ha scritto:
> > We decided not to add q6sizetype. Just add a "### Qt6: qsizetype" comment
> > where you can't use qsizetype in Qt 6. We'll deal with conflicts.
>
> Sorry, what
On Fri, Nov 22, 2019 at 03:01:25PM +0100, Uwe Rathmann wrote:
> On 11/22/19 11:01 AM, Friedemann Kleint wrote:
>
> > https://wiki.qt.io/Qt_Contributors_Summit_2019_Qt_6_Changes_/_Migration
>
> Maybe one aspect I would like to add: there is a lot of software, that has
> to be compilable with Qt 5
On Thu, Nov 21, 2019 at 07:48:41PM +0100, Oswald Buddenhagen wrote:
> On Thu, Nov 21, 2019 at 04:38:28PM +, Joerg Bornemann wrote:
> > There is the ongoing effort to replace the old outdated parser with a
> > clang, similar to what's been done in qdoc. The corresponding JIRA
> > issue is
On Mon, Nov 18, 2019 at 07:09:30PM +0100, Thiago Macieira wrote:
> On Monday, 18 November 2019 17:05:29 CET Lars Knoll wrote:
> > > On 18 Nov 2019, at 17:00, Kevin Kofler wrote:
> > >
> > > Thiago Macieira wrote:
> > >
> > >> The codecs we want to remove are just big tables of mapping old,
On Fri, Nov 15, 2019 at 05:47:04PM -0800, Thiago Macieira wrote:
> On Friday, 15 November 2019 16:23:24 PST André Pönitz wrote:
> > > The questions are:
> > > 1) do we want to prevent another library from accidentally unsetting it?
> > > 2) do we want c
On Thu, Nov 14, 2019 at 11:20:08PM -0800, Thiago Macieira wrote:
> On Thursday, 14 November 2019 13:27:23 PST André Pönitz wrote:
> > *Within* a Qt application consisting of Qt library, other libraries,
> > and actual user code it's mildly presumptous for one library to im
On Thu, Nov 14, 2019 at 12:10:24PM +0100, Mathias Hasselmann wrote:
>
> Am 03.11.2019 um 06:35 schrieb André Pönitz:
> > I am all for not propagating Qt's UTF-8 choice to child processes at all.
>
> "Write once, compile/run everywhere" mandates Qt enforcing a maximum
On Wed, Nov 06, 2019 at 12:38:48PM +, Edward Welbourne wrote:
> want. Sample options:
> * keep 1900-1999, discourage use of ShortFormat;
> * rolling window based on currentDate(), as I described earlier;
> * we update startYear's default with each major release of Qt.
First option seems to
On Mon, Nov 04, 2019 at 11:38:07AM -0800, Thiago Macieira wrote:
> On Monday, 4 November 2019 11:18:12 PST André Pönitz wrote:
> > A parser accepting the output of one might or might not be able to
> > handle the second.
>
> A driver would set LC_ALL in the environment when
On Mon, Nov 04, 2019 at 10:55:03AM -0800, Thiago Macieira wrote:
> On Monday, 4 November 2019 10:29:16 PST André Pönitz wrote:
> > All but one do not let the UI user change the environment, i.e. the
> > environment is passed through the Qt UI process (so far). The one is
> >
On Mon, Nov 04, 2019 at 09:40:00AM +, Edward Welbourne wrote:
> Indeed, what program would have problems in C.UTF-8 yet have a
> non-Unicode locale in which it works nicely ?
Other example:
echo x | LC_ALL="C.UTF-8" gcc -xc -
and
echo x | LC_ALL="C" gcc -xc -
produce different
On Mon, Nov 04, 2019 at 09:40:00AM +, Edward Welbourne wrote:
> On Friday, 1 November 2019 12:29:19 PDT André Pönitz wrote:
> >> a) and b) are fine with me, "c) yes" sounds like a potential problem.
> >>
> >> Most of the child process I usually call are
On Sat, Nov 02, 2019 at 06:16:36PM +0100, Kevin Kofler wrote:
> A true runtime option actually belongs in an environment variable, not in a
> method that has to be called by the compiled code. (In fact, that's what I
> would have expected your proposed QT_NO_OVERRIDE_LC_CTYPE to be, but
>
On Fri, Nov 01, 2019 at 02:49:36PM -0700, Thiago Macieira wrote:
> On Friday, 1 November 2019 12:29:19 PDT André Pönitz wrote:
> > > > My personal preference is:
> > > > a) C.UTF-8
> > > > b) override it to force UTF-8 on the same locale
> > > >
On Fri, Nov 01, 2019 at 09:21:48AM +, Lars Knoll wrote:
> > There are three questions to be decided:
> > a) What should Qt 6 assume the locale to be, if no locale is set?
> > b) In case a non-UTF-8 locale is set, what should we do?
> > c) Should we propagate our decision to child processes?
>
On Fri, Oct 18, 2019 at 12:24:12AM +0300, Ville Voutilainen wrote:
> On Fri, 18 Oct 2019 at 00:16, André Pönitz wrote:
> >
> > On Thu, Oct 17, 2019 at 09:04:36PM +0300, Ville Voutilainen wrote:
> > > Since we are about to do a major version upgrade, should be stop being
&
On Thu, Oct 17, 2019 at 09:04:36PM +0300, Ville Voutilainen wrote:
> Since we are about to do a major version upgrade, should be stop being
> a special snowflake in the C++ world and start attaching pointer-stars
> and reference-ampersands to the type instead of to the variable?
No.
And it's not
On Sun, Oct 06, 2019 at 06:19:37PM +, Timur Pocheptsov wrote:
> AndrЁ: I'm probably missing something, but ... yeah, it's about Vitaly,
> who's this Kirill you're talking about?
It's the person whose dashboard was linked to support Vitaly's nomination.
Andre'
On Wed, Oct 02, 2019 at 11:22:33AM +, Shawn Rutledge wrote:
> Hi all,
>
> I would like to nominate Vitaly Fanaskov as approver for the Qt Project.
> Vitaly joined the Qt Quick and Widgets team about a year ago. He has been
> fixing bugs in widgets and Qt Quick, making it easier to use and
On Thu, Sep 19, 2019 at 11:37:14PM +0200, Giuseppe D'Angelo wrote:
> Il 19/09/19 21:53, Kyle Edwards ha scritto:
> > As a generalization of this, perhaps Qt could introduce something like
> > a Q_CONSTEXPR macro, which does what we expect on platforms that
> > support it, and compiles to nothing
On Thu, Sep 19, 2019 at 09:14:36PM +0200, Giuseppe D'Angelo via Development
wrote:
> On 19/09/2019 21:01, André Pönitz wrote:
> > "Is it worth" is exactly the question that should drive this kind of
> > discussion.
> > And it can be answered_after_ evaluati
On Thu, Sep 19, 2019 at 11:18:26AM +0200, Mutz, Marc via Development wrote:
> But it helps nothing with all the places where we use QWaitCondition in Qt
> implementation and would like to replace it with std::condition_variable +
> std::mutex, because, as I explained in an earlier mail,
On Thu, Aug 22, 2019 at 08:48:30PM +0200, André Pönitz wrote:
> On Thu, Aug 22, 2019 at 05:39:07PM +0200, Mutz, Marc via Development wrote:
> > I'm sorry if I sound blunt, but this is just nonsense. What you call
> > optimisation, isn't. Using QStringLiteral or QLatin1St
On Thu, Aug 22, 2019 at 05:39:07PM +0200, Mutz, Marc via Development wrote:
> I'm sorry if I sound blunt, but this is just nonsense. What you call
> optimisation, isn't. Using QStringLiteral or QLatin1String is equally
> readable. As is just using "".
I am not sorry to sound blunt here, but
On Wed, Aug 21, 2019 at 10:01:29AM +, Tor Arne Vestbø wrote:
> > On 21 Aug 2019, at 11:50, Bogdan Vatra via Development
> > wrote:
> >
> > Am I the only one which finds situations silly ? Of course there are more
> > examples
> > with the other String wrappers/functions in Qt, but I think
ficant
> development effort to replicate independently.
Such context is always good.
> On 8/5/19, 1:39 PM, "André Pönitz" wrote:
> Would it be possible to use a less overloaded name? After a bit of
> search I think I get now what it refers to, but it surely was not my
On Mon, Aug 05, 2019 at 10:35:37AM +, Stottlemyer, Brett (B.S.) wrote:
> Hi,
Hi Brett.
> I’d like to request a new branch (“acme”) on QtCreator.
Would it be possible to use a less overloaded name? After a bit of search
I think I get now what it refers to, but it surely was not my first
1 - 100 of 426 matches
Mail list logo
