Re: [Development] A QStringList puzzle for Monday

I really want to highlight Igors advice to define QT_NO_CAST_FROM_ASCII. It really removes countless traps when using Qt, and will give you a much more pleasant experience. To avoid bloating you code with QString{}, QStringLiteral{} or QLatin1String{} boilerplate after enabling QT_NO_CAST_FROM

Re: [Development] Proposing to change https://wiki.qt.io/API_Design_Principles#Enums_in_classes to require scoped enums

Am 16.01.25 um 11:56 schrieb Marc Mutz via Development: Hi, Groundhog Day... Like every API review, so also in 6.9, we have the discussions between proponents of scoped vs. unscoped enums in class scope. Can we, please, settle this by strengthening the wording of https://wiki.qt.io/API_Design

Re: [Development] format-like tr()

Am 23.10.2024 um 11:22 schrieb Ivan Solovev via Development: Hi Thiago, first of all, could you please clarify, how do you see the potential implementation? Do you think that we can reuse some of the things that std::format provides, or do we need to write everything from scratch? For my patc

Re: [Development] Switching Qt default builds to C++20 where supported

The QtCS24 misses the single one big reason you want to switch C++20 now and whenever possible: Concepts. They indeed are a total game changer and I'd boldy predict that 80% of all meta-programming helpers in Qt's headers could be replaced by concepts that are easier to understand, more expressi

Re: [Development] Proposal to retain \since version information in Qt Documentation

Am 24.09.2024 um 19:24 schrieb Christian Ehrlicher via Development: Am 24.09.2024 um 15:12 schrieb Paul Wicking via Development: Dear Qt Developers, I am writing to address a series of recent code review changes that propose removing the `\since [version]` documentation strings from various

Re: [Development] (Bikeshed, pedantic) East constexpr vs West constexpr

Am 18.09.2024 um 17:18 schrieb Thiago Macieira: Which one are we? That is, constexpr inline foobar or inline constexpr foobar Why that "inline" attributes at all? For functions and static data members the "constexpr" attribute implies "inline" already: https://timsong-cpp.github.io/cpp

Re: [Development] Removing Qt 3D from release configuration in dev branch

I am really confused by this thread. If I read Jani's mail correctly, the plan is:     Keep everything as it is, except for adding Qt3D to the installers? Or more exaggerated:     Keep everything as it is, except for the official endorsement. Or even more exaggerated:     Keep everything as

Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?

Am 21.02.2024 um 20:28 schrieb Thiago Macieira: On Wednesday, 21 February 2024 10:56:49 PST Edward Welbourne via Development wrote: (Incidentally, the ways I can think of to say "has no name" tend to suffer from some degree of precedent as "has a name but it has not been disclosed" - the anonym

Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?

Am 21.02.2024 um 17:36 schrieb Thiago Macieira: On Wednesday, 21 February 2024 08:26:52 PST Jøger Hansegård via Development wrote: Our Qt coding conventions (https://wiki.qt.io/Coding_Conventions) has a statement on the use of unnamed (anonymous) namespaces. As far as I understand, this stateme

Re: [Development] Request for early MOC support for C++20 Modules

Am 16.12.2023 um 09:21 schrieb apoenitz: I haven't tried yet, but I have the gut feeling that one should be able to get away with Seems your gut feeling is right. Did a little experiment[1], and ended up with this: class MyObject :public Object { M_OBJECT public: using Object::

Re: [Development] Future of java-style iterators?

Hi, would QDirIterator[1] be part of this deprecation? Its API clearly seems be inspired by the Java-style iterators. While I do not care much about the other Java-style iterators, I really like this iterator and use it a lot. What would be this iterator's modern replacement in Qt? Ciao Mat

Re: [Development] The sorry state of the Qt6 cross compile experience

Am 23.02.2021 um 13:27 schrieb Marius Kittler: The multi-ABI build never worked well for me with Qt 5. While it is nice that Qt's build system offers this feature it doesn't help with the fact that other dependencies of my project don't support that. Hence it is still easier to install each arch

Re: [Development] The sorry state of the Qt6 cross compile experience

Am 24.02.2021 um 09:30 schrieb Bogdan Vatra via Development Let's check some numbers: [...] So, for 100M, you've added +700M. Cost for storing one GiB of information on a SDD? Below 10 Cents. What do you charge your customers for just one minute of watching your computer recompiling Qt? W

Re: [Development] Is qsizetype *documented* to be ptrdiff_t?

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. Am 01.09.2020 um 19:29 schrieb Thiago Macieira: On Tuesday, 1 September 2020 08:44:07 PDT Giuseppe D'Angelo via Development wrote: Il 01/09/20

Re: [Development] qsizetype and classes working with QStrings or QList

Am 25.08.2020 um 01:09 schrieb Thiago Macieira: On Monday, 24 August 2020 15:10:24 PDT Иван Комиссаров wrote: It would be nice if QAbstractItemModel will support qsizetype instead of int, but I do not see how this is possible considering the fact that rowCount/columnCount return int. I suppose,

Re: [Development] qsizetype and classes working with QStrings or QList

Am 24.08.2020 um 11:04 schrieb Ville Voutilainen: On Mon, 24 Aug 2020 at 10:50, Mathias Hasselmann wrote: Am 24.08.2020 um 09:26 schrieb Giuseppe D'Angelo via Development: On 23/08/2020 16:06, Marcel Krems wrote: If they keep using int there could be a lot of warnings like this one: wa

Re: [Development] qsizetype and classes working with QStrings or QList

Am 24.08.2020 um 09:26 schrieb Giuseppe D'Angelo via Development: 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 'int' [-Wshorten-64-to-32] I

Re: [Development] [RFO QTBUG-84739] QJsonValue::fromVariant containing QByteArray

Am 01.07.2020 um 23:21 schrieb Thiago Macieira: Re: https://bugreports.qt.io/browse/QTBUG-84739 Summary: Qt 5.15 has an unintentional change in behaviour that has broken existing applications. We need to decide whether to: a) leave as-is b) revert permanently c) revert for 5.15.x but keep

Re: [Development] Changes to Qt offering

Am 27.01.2020 um 15:34 schrieb Lars Knoll: Hi all, The Qt Company has done some adjustments to the Qt will be offered in the future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 . The change consists of three parts. One is a change in policy regarding the LTS releases, whe

Re: [Development] QTCS2019 Notes from QtQml session

Am 25.11.2019 um 15:39 schrieb André Somers: On 25-11-19 12:31, Ulf Hermann wrote: I think one of the biggest problems is that ID resolution crosses file boundaries. This essentially means that the ids chosen can very easily become part of the "API" of a component unless you are very vigilant

Re: [Development] RFC: QVariant changes in Qt6

OMG, are you really sure about these massive changes? I am pretty sure that this will introduce countless hard to catch porting issues. After all there are no compiler warnings for this, only subtile behavior changes and I doubt that all the Qt based projects out there have sufficient test cov

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

Am 03.11.2019 um 06:35 schrieb André Pönitz: 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_

[Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

Am 21.08.2019 um 19:38 schrieb Thiago Macieira: PPS: can we drop MinGW support in Qt 6? What alternative do you propse? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] QButtonGroup: When the "right thing to do" is absolutely the wrong thing to do

Hi Boudewijn, these kind of refactorings are neccessary to keep code maintainable I fear. Anyway, it seems like you are maintaining a bunch of custom patches on top of Qt? How about reducing your maintainance burden by upstreaming them? Qt would benefit from bugfixes and new features. You woul

Re: [Development] Create native FileDialog for Android

Heya, The general approach to this kind of tasks is to: - add your own Android activity that extends org.qtproject.qt5.android.bindings.QtActivity - have that activity provide a public method doing all the native Android calls - and to finally invoke this method from C++ via QtAndroid::a

Re: [Development] Symbol clashes with static Qt libraries

Am 31.07.2018 um 14:58 schrieb Edward Welbourne: Giuseppe D'Angelo (31 July 2018 14:38) It will likely break every single application that has never used a namespaced build of Qt. Which is a significant percentage of all the Qt apps out there... I'm guessing you mean "... used a static buil

Re: [Development] #pragma once

Let's see what people who know much more about compiler features than any of us think about "#pragma once". Let's check what GCC and Clang do for their C++ library headers: $ grep -r pragma.*once /usr/include/clang/5.0.0/include /usr/include/c++/7.2.0/ $ ...and this is about headers that

Re: [Development] syncqt.pl in C++

y basically have to circumvent countless company policies just to bootstrap Gradle. Besides I somehow doubt that it is even remotely reasonable to mimic a build system that weights 225 MiB in size. Tools should know their task and focus on that. No need for a kitchen sink. Ciao, Mathias --

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

ot delivering bugfix releases for arbitrary reasons we are risking to kill Qt's credibility as reliable toolkit. Our users trust in getting bugfix releases. Ciao, Mathias -- Mathias Hasselmann | mathias.hasselm...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group

Re: [Development] Decrease amounth of delivered src packages

Am 15.02.2017 um 18:08 schrieb Konstantin Tokarev: 15.02.2017, 20:07, "Thiago Macieira" : On quarta-feira, 15 de fevereiro de 2017 09:04:12 PST Konstantin Podsvirov wrote: This can be not quite on this topic, but I have a suggestion and MVP implementation for QtIFW. This may affect the

Re: [Development] Decrease amounth of delivered src packages

Am 15.02.2017 um 13:05 schrieb Dmitry Shachnev: On Wed, Feb 15, 2017 at 12:28:11PM +0100, Kevin Kofler wrote: I would kindly request you to at least use tar.xz (rather than tar.gz) for the tarballs. (What you use as the Windows format is something you need to sort out with the Windows people.)

Re: [Development] A new approach for Qt main()

Hi, Seems this turned into a nice bike shed discussion quickly, so let me use the chance to present my preferred Qt main(). I am totally convinced that this one should rule the Qt world: class BlueBikeShedApplication : public QApplication { Q_OBJECT public: using

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

Am 22.09.2016 um 00:58 schrieb André Pönitz: On Wed, Sep 21, 2016 at 08:57:01AM +0200, Olivier Goffart wrote: No, it's not. It's changing undefined behavior into defined behavior. But in many case, we want to put something in a QVariant, and we never compare this variant. Forbidding types t

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

Am 21.09.2016 um 12:00 schrieb Marc Mutz: On Wednesday 21 September 2016 11:42:41 Mathias Hasselmann wrote: No matter what order I use for config and value, the compiler will pad and -Wpadded will complain. How am I supposed to fix this? This solutions that come to my mind all are ugly, but

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

Am 21.09.2016 um 09:52 schrieb Marc Mutz: On Wednesday 21 September 2016 09:23:35 Mathias Hasselmann wrote: Maybe some clever use of type traits can tell us if your structs contain alignment wholes? -Werror=padded :) Yes, but how is it supposed to help? Let me show a real world example

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

Am 21.09.2016 um 08:57 schrieb Olivier Goffart: On Mittwoch, 21. September 2016 08:01:22 CEST Mathias Hasselmann wrote: As much as I'd like to debug this code now to prove me right, I sadly have deadlines to meet this week. So I have to behave myself to not dig up the code right now.

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

Am 20.09.2016 um 12:44 schrieb Olivier Goffart: On Dienstag, 20. September 2016 12:21:11 CEST Mathias Hasselmann wrote: Am 19.09.2016 um 23:27 schrieb Olivier Goffart: We really cannot have a qHash for QVariant anyway, because that would imply that ALL QVariant can be hashed, and compared

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

Am 19.09.2016 um 23:27 schrieb Olivier Goffart: We really cannot have a qHash for QVariant anyway, because that would imply that ALL QVariant can be hashed, and compared. Which is not the case. Most custom types don't even register comparator function. Which actually is quite a serious issue,

Re: [Development] Qt API review with clazy

Hello Chris, On 12 September 2016 at 19:06, Mathias Hasselmann wrote: Just that the approach of clang-tidy is fundamentally wrong: Hi Mathias, No offense, but you arguments are fundamentally wrong too. Your workflow is not everyone's workflow! You simply don't do static c

Re: [Development] Qt API review with clazy

Am 12.09.2016 um 09:33 schrieb Konstantin Tokarev: Use Q_ENUM instead of Q_ENUMS Q_ENUM increases amount of metacode generated for enum. Is it really a good idea to replace Q_ENUMS everywhere? One thing that makes Qt easy to use is consistency. Once you know enough of its classes using most

Re: [Development] Qt API review with clazy

Just that the approach of clang-tidy is fundamentally wrong: You simply don't do static checks as a after thought, at random times when sun, mars and moon are in proper constellation. Why? Because when running this checks occasionally too much cruft will have accumulated that it is worth and

Re: [Development] commas in ctor-init-lists

emove Not mentioned yet: Conditional compilation vs. stable ABI: MamanBar::MamanBar(...) : m_field1(...), m_field2(...),// oh... #ifdef FEATURE1_ENABLED m_field3(...),// ...ah #endif #ifdef FEATURE2_ENABLED m_field4(...) #endif { }

Re: [Development] commas in ctor-init-lists

work-around. By your choice of wording you seem rather upset. For myself I know that I feel upset when my comfort zone gets violate, when someone tries to changes things I grew comfortable with. How are the chances that you are upset just for the very same reason? Ciao, Mathias -- Mat

Re: [Development] Qt Coding Guidelines

Am 17.03.2016 um 10:01 schrieb Sorvig Morten: How about treating the coding guidelines as \internal documentation? We could then at some point build and publish it together with the rest of the \internal's. (suitably separated from the public user documentation) Actually having the Qt code st

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

Am 29.02.2016 um 17:40 schrieb Thiago Macieira: On segunda-feira, 29 de fevereiro de 2016 13:21:52 PST Milian Wolff wrote: What do you say? What am I missing that would break my assumptions? This is what Olivier proposed too. Like I said, I don't like it, but it works. Well, and it's propo

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

Am 25.02.2016 um 19:22 schrieb Milian Wolff: Can you explain what those reasons are? I'd really love to write a generic QAbstractTableModel implementation that operates using concepts. Currently that would require type erasure and thus another set of virtual function calls... I.e. in many proje

Re: [Development] Scalable UIs in QtQuick (take 2)

Am 18.02.2016 um 11:50 schrieb Hausmann Simon: > A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical dimens

Re: [Development] Question about QCoreApplicationData::*_libpaths

Am 21.01.2016 um 08:00 schrieb Marc Mutz: On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote: Marc Mutz wrote: On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote: All these are horrible and error-prone hacks that have obvious lifetime issues. You are complaining about Qt containers

Re: [Development] Question about QCoreApplicationData::*_libpaths

Am 19.01.2016 um 15:21 schrieb Ziller Eike: On Jan 19, 2016, at 16:09, Marc Mutz wrote: I doubt many people actively use the fact that Qt containers are cheap to copy. Each and every developer that uses Qt uses the fact that Qt containers are cheap to “copy" class A { public: QVector

Re: [Development] Question about QCoreApplicationData::*_libpaths

Am 16.01.2016 um 01:29 schrieb Kevin Kofler: Now, what *I* find "simply *not acceptable*" is that "a seemingly innocuous piece of code like": std::vector foo1 = …; std::vector foo2 = foo1; // <- here "leads to a memory allocation, nay, a complete deep copy of the container". This is particularl

Re: [Development] Question about QCoreApplicationData::*_libpaths

Am 05.01.2016 um 14:41 schrieb Thiago Macieira: On Tuesday 05 January 2016 15:37:51 Marc Mutz wrote: On Tuesday 05 January 2016 12:56:55 Ulf Hermann wrote: avoid paying the price of constructing a QStringList if they are unused. That's what I was wondering about: constructing a QStringList

Re: [Development] RFF: nullptr rules

Am 09.12.2015 um 17:45 schrieb Mathias Hasselmann: Am 09.12.2015 um 16:14 schrieb Marc Mutz: Arguments in favour: - it's the C++ way of writing the null pointer constant these days - we need to use it in headers, anyway, to allow people to use -Wzero-as..., and it makes no sense to

Re: [Development] RFF: nullptr rules

Am 09.12.2015 um 16:14 schrieb Marc Mutz: Arguments in favour: - it's the C++ way of writing the null pointer constant these days - we need to use it in headers, anyway, to allow people to use -Wzero-as..., and it makes no sense to have two sets of rules for headers and impl - it can disamb

Re: [Development] toLower() vs. toCaseFolded()

Am 09.12.2015 um 12:20 schrieb Marc Mutz: On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote: * Marc Mutz [2015-12-09 11:54:54 +0100]: Hi, http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what case folding actually _is_ and how it's different from toLower(). Can so

Re: [Development] RFC: more liberal 'auto' rules?

Am 07.12.2015 um 15:39 schrieb Marc Mutz: - auto everywhere in C++ means that the type of the rhs defines the type of the variable To the extreme of having: auto x = Type { init }; Instead of: Type x(init); ...if you follow Herb Sutter to the extreme[1]. It feels quite extreme i

Re: [Development] QTime microsecond support

Plus user defined literals (for hours, minutes, seconds) and adoption in QTimer and friends. Am 15.10.2015 um 14:18 schrieb Edward Sutton: > +1 for naming QTimeSpan with support for arithmetic operators. > > On Thursday 15 October 2015 02:09:07 Aleix Pol wrote: >> Maybe you could look into forkin

Re: [Development] Are SiCs through #include cleanups considered acceptable?

Am 10.04.2015 um 17:51 schrieb Thiago Macieira: > On Friday 10 April 2015 15:03:04 André Somers wrote: >> I do think it needs a bit of work on the documentation side of things to >> make it clear that really any QList now behaves as/is a >> QByteArrayList. The documentation still says it is a cla

Re: [Development] Are SiCs through #include cleanups considered acceptable?

Am 10.04.2015 um 17:51 schrieb Thiago Macieira: > On Friday 10 April 2015 09:51:42 Christian Kandeler wrote: >> On 04/09/2015 08:51 PM, Thiago Macieira wrote: >>> The objective is to make Qt6 QStringList be a typedef to QList, >>> not a separate class. >> >> Uh-oh, that will break all forward dec

Re: [Development] QtCore missing check for memory allocation

Am 25.02.2015 um 17:34 schrieb Ulf Hermann: > >> Also, you are not even guaranteed to get a null pointer/bad_alloc >> due to things like Linux overcommitting. > > Overcommitting is not dangerous as it will reliably lead to the > process getting killed if it goes wrong. If you can exploit that, we

Re: [Development] QtCore missing check for memory allocation

Am 25.02.2015 um 16:48 schrieb Ulf Hermann: > The point is this: With the current behavior you're not actually > guaranteed to get a segfault. The client code might not access *p, > but rather p[], and that might hit valid memory. > Or it might store p, do whatever funny arithmetic on it with the

Re: [Development] Mime database size

Am 23.02.2015 um 08:11 schrieb Thiago Macieira: > On Monday 23 February 2015 07:48:37 Mathias Hasselmann wrote: >> Am 17.02.2015 um 14:36 schrieb Cristian Adam: >>> One could rewrite this small utility into Qt and then it would be >>> available everywhere. >> >

Re: [Development] Mime database size

Am 17.02.2015 um 14:36 schrieb Cristian Adam: > One could rewrite this small utility into Qt and then it would be > available everywhere. Somehow I thought that one of the big benefits of free software and open source is, that you _don't_ have to rewrite each and every simple tool. Obviously I'v

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Am 19.02.2015 um 20:47 schrieb Matthew Woehlke: > On 2015-02-19 14:28, Thiago Macieira wrote: >> On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote: >>> That on a non-const shared container >>> >>> for (auto i : container) >>> >>> will detach it. That's why having rules instead of sayi

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

NO, please. Just use std::cref(). The feature is there already in the STL. Am 19.02.2015 um 20:36 schrieb Thiago Macieira: > On Thursday 19 February 2015 12:07:04 Matthew Woehlke wrote: >> On 2015-02-19 07:29, Daniel Teske wrote: >>> Qt's container classes and C++11 range based for loop do not mix

Re: [Development] Why can't QString use UTF-8 internally?

Am 11.02.2015 um 10:11 schrieb Marc Mutz: > You overlooked "where a corresponding character exists". Either uppercase ß > exists (it does, it was found in an old printing, so there's a movement to > adopt it, except Unicode doesn't have it), then it's not a problem, or it does > (as is the case

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Am 10.02.2015 um 20:13 schrieb André Pönitz: > On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote: >> On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote: >>> On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote: +1. I’m ok with us making sure our headers are clean against war

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Am 09.02.2015 um 15:40 schrieb Marc Mutz: > On Monday 09 February 2015 09:54:12 Smith Martin wrote: >> This is the kind of thing we should add to the documentation, but can you >> elaborate? I mean, illustrate the meaning of "locality of reference," >> "wildly mixing insertions, lookups, and remo

Re: [Development] Feature freeze approaching

I'd also like to mention those patches improving anti-aliasing and providing the option to use FreeType for text rendering on OSX: https://codereview.qt-project.org/#/c/105258/ https://codereview.qt-project.org/#/c/105225/ https://codereview.qt-project.org/#/c/105226/

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Am 09.02.2015 um 08:48 schrieb André Somers: > Mathias Hasselmann schreef op 8-2-2015 om 22:28: >> >> Am 08.02.2015 um 14:28 schrieb Marc Mutz: >> >>> c. Using QMap. As Alex Stepanov put it: every use of a map should be >>> discussed >>> in

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Am 09.02.2015 um 00:07 schrieb Allan Sandfeld Jensen: > I am not a big fan of nullptr, Out of curiosity: What's wrong with nullptr in your opinion? Ciao, Mathias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailm

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Am 08.02.2015 um 14:28 schrieb Marc Mutz: > c. Using QMap. As Alex Stepanov put it: every use of a map should be discussed > in a face-to-face meeting with your manager. Since we don't have that, I'd > change this to: Everyone wishing to use a QMap should implement one before > using

Re: [Development] Requesting a break in behavior in QML Text element

Am 30.01.2015 um 08:12 schrieb Bo Thorsen: > Den 29-01-2015 kl. 23:24 skrev Robin Burchell: >> Hi, >> >> Rationale: Text.AutoFormat is a terrible misfeature in almost every >> case out there. >> [...] > > I agree that it would be better to set plain text as the default. In > most cases it's what

Re: [Development] Compiler warnings

Am 17.10.2014 um 18:31 schrieb Thiago Macieira: > On Friday 17 October 2014 13:06:39 Milian Wolff wrote: >> enum Foo { >> Bar = 1, Baz = 2 >> }; >> >> Foo foo = static_cast(3); >> >> Now what do you do without a default clause? > > Shoot the developer who abused the API. > > If the function accep

Re: [Development] Compiler warnings

Am 17.10.2014 um 13:16 schrieb Kurt Pattyn: > >> On 17 Oct 2014, at 12:54, Sean Harmer wrote: >> >> On 17/10/2014 11:44, Bo Thorsen wrote: >>> Den 17-10-2014 12:22, Julien Blanc skrev: On 17/10/2014 10:15, Christian Kandeler wrote: > On 10/17/2014 08:48 AM, Kurt Pattyn wrote: >> As

Re: [Development] QConfig update.

Am 14.10.2014 um 18:44 schrieb Tomaz Canabrava: > On Tue, Oct 14, 2014 at 1:35 PM, Milian Wolff > wrote: > >> On Tuesday 14 October 2014 13:22:51 Tomaz Canabrava wrote: >>> QConfig and QConfigGroup *does not* support setting a default value >>> on the getter, I kno

Re: [Development] Adding new network tests

Am 12.06.2014 08:16, schrieb Mandeep Sandhu: >> Whenever possible, use the mini-http server, as it is less likely to cause >> network timeouts. > Ok. Although since I'm testing out a lot of redirection scenario's, it > might be better to use a real webserver for generating different types > of red

Re: [Development] Proposal: "rebranding" QMF as QtMail

Am 10.02.2014 17:02, schrieb Robin Burchell: > Hello folks, > > After some build system reworking recently and a little discussion > amongst the interested parties (Matt Vogt, Valerio), I'd like to > propose renaming QMF (Qt Messaging Framework) to QtMail with the > longer term goal of making it a

Re: [Development] Enginio build artifacts and naming conventions

As a side note: A similar problem exists for the messaging framework libraries (QMF). Its library names are: libQmfClient.so.5.0.0 libQmfMessageServer.so.5.0.0 libQmfWidgets.so.5.0.0 Ciao, Mathias Am 26.05.2014 20:54, schrieb Stephen Kelly: > Hello, > > This tweet was brought to

Re: [Development] qHash / QHash changes

Am Montag, den 19.03.2012, 10:42 +0100 schrieb Thiago Macieira: > On segunda-feira, 19 de março de 2012 10.04.28, Mathias Hasselmann wrote: > > Am Montag, den 19.03.2012, 08:01 + schrieb Giuseppe D'Angelo: > > > 2) Document to end users that it cannot be assum

Re: [Development] qHash / QHash changes

Am Montag, den 19.03.2012, 08:01 + schrieb Giuseppe D'Angelo: > 2) Document to end users that it cannot be assumed that qHash output or QHash > iteration order are stable, so people must not rely on that. Would that be sufficient to prevent 3rd-party code relying on stable iteration order from

Re: [Development] Header file cleanups

Am Donnerstag, den 01.03.2012, 11:27 + schrieb lars.kn...@nokia.com: > On 3/1/12 11:02 AM, "ext Thiago Macieira" > wrote: > > >On quinta-feira, 1 de março de 2012 08.22.42, lars.kn...@nokia.com wrote: > >> Hi, > >> > >> I've seen a few examples where people are cleaning up includes in header

Re: [Development] On qbs use inside Qt

Am Donnerstag, den 16.02.2012, 12:19 +0100 schrieb Thiago Macieira: > Ok, so you have now all seen Jörg's blog about qbs. If you haven't, please go > read it before continuing: > > http://labs.qt.nokia.com/2012/02/15/introducing-qbs/ > > Let me also remind you of the past discussions on bu

Re: [Development] Removing QContactThumbnail class from QtContacts API

_ > Subject to local law, communications with Accenture and its affiliates > including telephone calls and emails (including content), may be > monitored by our systems for the purposes of security and the > assessment of internal compliance with Accenture policy. > __ > > www.accenture.com > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Mathias Hasselmann http://openismus.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

[Development] Let's discuss QPluginManager

d reuse? Guess this should be enough to get the discussion started. Thank you, Mathias -- Mathias Hasselmann http://openismus.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] fixing name of QNetworkAccessManager::createRequest

Am Freitag, den 13.01.2012, 13:00 + schrieb Giuseppe D'Angelo: > On 13 January 2012 12:32, Mathias Hasselmann wrote: > >> what about the slightly more garden-variety approach of deprecating > >> the old one and introducing a new method? > > > > May

Re: [Development] fixing name of QNetworkAccessManager::createRequest

uses creation of a network request. Now this network request is just an internal object, and not exposed to the API user. Instead the watchable reply object is returned in advance. Not really an issue, and not entirely uncommon in async APIs IMHO. Ciao,

Re: [Development] QLatin1Constant and QtContacts / QtOrganizer

++ not being able to resolve which of its cast operators shall be used (QString vs. QLatin1String). Also I never really got is purpose: To enable comparison and hashing of QtContact's string keys, and to make sure those strings don't wast

Re: [Development] QContactLocalId in Qt5

Am Dienstag, den 01.11.2011, 14:05 +0100 schrieb Mathias Hasselmann: > Am Dienstag, den 01.11.2011, 09:56 +0100 schrieb Robin Burchell: > > Hi Paivi, > > > > > Another step towards that direction would be to hide the internal format > > > of > > > backe

Re: [Development] QContactLocalId in Qt5

olution we found to work around QtContacts limitations is... hideous: https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/engine/engine.cpp#line1794 https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/engine/contactidfetchrequest.cpp#line52 Ciao, Mathias -- Mathias Hasselmann http://openismus.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Other buildsystems

the documentation and cleaning up the mkspecs folder instead? Surely not the most fancy job, but maybe much more reasonable than doing things from scratch or even mixing stuff. Ciao, Mathias [1] Says someone with strong roots in autotools, but fully acce

Re: [Development] QContactLocalId in Qt5

Should learn to focus! :-) QContactManagerEngineV2 - right now it is marked as interface, but actually it extends QContactManagerEngine. So I'd propose to either merge its virtual methods into QContactManagerEngine, or to make it a real interface (by not inheriting QContactManagerEngine

Re: [Development] QContactLocalId in Qt5

uld be made public, so that engines can warm the cache, or even better that code should be change to use some better memory allocator. Slab, like successfully used by GSlice would be an option. Adrien has more details. Ciao, Mathias -- Mathias Hasse