Re: [Development] Nominating Ivan Komissarov as approver

Hello, > I'd like to nominate Ivan Komissarov as an approver. +1 André Am 07.05.2020 um 10:23 schrieb Christian Kandeler: Hello, I'd like to nominate Ivan Komissarov as an approver. Ivan has been doing valuable work in the qbs project for a while now, both as a contributor and a reviewer. I

Re: [Development] Session notes for "Code Review: Sharing the load" and follow-up session

Hi Nils, thanks for the summary. I have two additions: * Reactivate the QDoc bot to sanity check the docs * Improve the output of sanity bot, especially for new users: https://bugreports.qt.io/browse/QTQAINFRA-1478 Best regards, Andre Am Mittwoch, 20. November 2019 schrieb Nils Jeisecke via

Re: [Development] Gerrit: Sanity-Review is lost after moving changes

Or if it is, the sanity bot should probably be triggered again. > yes, make a jira task for qtqainfra/sanity bot. Done: https://bugreports.qt.io/browse/QTQAINFRA-3026 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/

Re: [Development] Why are my merged patches not in dev after checkout?

9795101519a9 > Change-Id: I2d269ef0f842e73af64d48bfef531d5fa3078088 > > What am I doing wrong? > > Regards, > > Daniel Savi Andre ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.

Re: [Development] QUIP 6: removing top-level const from return types

Qt 6. Neither the macro ugliness would be needed in this case nor would we have a compiler dependency. If you insist that such a change is allowed by QUIP-6 (and actually I agree that it is by the current wording) then QUIP-6 should be amend

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

or hold back calls, or possible finalize initialization or whatever using the registered callbacks. For me it would be helpful to have a list of problems that need to be solved before discussing one specific potential solution. Andre' From: Devel

[Development] Qt API consistency (was: Re: unique_ptr vs. QSharedPointer)

I'd like another question be answered before the discussion on yet another unsystematic use of yet another language or library feature starts: How important is API consistency for Qt today? Andre' ___ Development mailing list Deve

Re: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI]

Sean Harmer wrote: > On Monday 21 March 2016 12:23:44 Poenitz Andre wrote: > > I will argue that if user code looks ugly by default, or needs one specific, > > controversial coding style when using an API, the API is bad. > > > > A possible question here is why

Re: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI]

Marc Mutz wrote: > On Monday 21 March 2016 12:07:24 Poenitz Andre wrote: > > Marc Mutz wrote: > > > I said then and I repeat it now that imho template aliases are not > > > interesting for library development. In particular, I don't think > > >

Re: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI]

it shall not be hidden by a template alias whereas it would be completely fine to hide everything related to type by using auto? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Fixing QRect::width() / height()

rrectly. Adding a second width() version is exactly that: It designs an API that's harder to use ("which version do I need"?), leaves all existing users in the rain, and would trigger major changes in code that wants to adapt. Clamping width() fixes the problem for existing user code a

Re: [Development] Fixing QRect::width() / height()

dth() to return a bounded result to avoid UB for > old users, but we need a code path that returns the correct result for new > users without everyone of them going quint64(1) + r.right() - r.left() by > themselves... You seem to claim that new users would need 64 bit QRects. Th

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

On 23-1-2016 17:39, Milian Wolff wrote: On Freitag, 22. Januar 2016 22:51:30 CET Kevin Kofler wrote: Marc Mutz wrote: And this is where I stop taking you seriously, sorry. You can demand such nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+ algorithms from the STL for Qt

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

On 22-1-2016 22:51, Kevin Kofler wrote: I'd already be happy with those that were (are, actually) already there. I'd rather have 10-20 common algorithms with a convenient API than 80+ obscure ones that force me to use iterators (especially the boilerplate .begin() and .end() iterators that will

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

On 21-1-2016 21:09, Milian Wolff wrote: On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote: Op 21/01/2016 om 05:35 schreef Thiago Macieira: On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote: Thiago Macieira wrote: The copy constructor is called once, then the move constructo

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

kes sense. Use your own judgement, but remember: fear is a bad advisor." pretty much opens the door for AAA, as for an AAA supporter "auto" will *always* make sense. So effectively the proposal consists of two attempts to implement an AAA policy. That's going way too far in one step. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

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

default in Creator code for a while before the then-matured implementation goes to the library. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

On 27-7-2015 18:13, Thiago Macieira wrote: > On Monday 27 July 2015 08:44:30 Knoll Lars wrote: >> I can understand the issues that non latin speakers are facing with this >> well. I’ve often used qDebug() to debug non latin use cases, and in 90% of >> the cases I just want to know what the string r

Re: [Development] Qt LTS & C++11 plans (CopperSpice)

On 27-7-2015 18:21, Thiago Macieira wrote: > On Monday 27 July 2015 08:01:53 André Somers wrote: >> I am not a lawer and I don't know the wording of the KDE Free Qt >> Foundation agreement, but are you sure that in case that agreement is >> triggered the verion you branched off off will fall under

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On 12-7-2015 19:56, Smith Martin wrote: >> If it doesn't, then why not choose QVector? > My intent in getting the information from Marc is to change the documentation > of QList to say that. > > But QList is easy to use. How is it easier to use than QVector? I will grand you two: QList is two cha

Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5

On 13-5-2015 2:44, Thiago Macieira wrote: > On Wednesday 13 May 2015 02:34:28 Jan Kundrát wrote: >> Hi, >> this commit [1] added a new overload to QTextStream::readLine. As a result >> of that, calling stream.readLine(0) is now ambiguous: >> >> QString readLine(qint64 maxlen = 0); >> bool

Re: [Development] Future of Qt Quick 1 in Qt 5

On 8-5-2015 18:47, Hausmann Simon wrote: > Hi, > > If the public API would allow you to implement what the folks at KDAB did at > http://www.kdab.com/creating-pdf-qtquick-2-scene-slideviewer/ ‎, would that > help your use case? What they basicaly did was reimplement the Quick elements they were

Re: [Development] RFC: RAII for property changes

On 15-4-2015 21:05, Keith Gardner wrote: > QPropertyGuard g{this}; > g.addProperty("a"); // use QObject::property > g.addProperty("b", m_b); // take value member by reference > g.addProperty(m_c, &cChanged); // ...and also slot address There's type erasure going on, s

Re: [Development] RFC: RAII for property changes

On 15-4-2015 18:44, Matthew Woehlke wrote: > The second form would thus save the value <-> QVariant comparison and > not much else. The third form however eliminates the string look-up > entirely by having the user provide both the backing member variable > *and* what to do when a change should

Re: [Development] RFC: RAII for property changes

On 15-4-2015 17:08, Matthew Woehlke wrote: > On 2015-04-15 10:43, Marc Mutz wrote: >> On Wednesday 15 April 2015 11:49:56 André Somers wrote: >>> void MyClass::setFoo(QString value) >>> { >>> PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY >>> Q_UNUSED(guard); >>> >>>

Re: [Development] RFC: RAII for property changes

On 15-4-2015 16:54, Keith Gardner wrote: On Wed, Apr 15, 2015 at 9:38 AM Marc Mutz > wrote: Hi André, On Wednesday 15 April 2015 11:49:56 André Somers wrote: > void MyClass::setFoo(QString value) > { >PropertyGuard guard(this, "foo"); //foo

Re: [Development] Compiler warnings

me > > be hit. > > On second thought, I think this is a very bad example. Even while you keep > binary compatibility, you break semantics here. > This is typically a case where one should break binary compatibility. Are you seriously asking for a new major Qt release just

Re: [Development] New company name for Qt part of Digia and unified web site

On 16-9-2014 20:50, Knoll Lars wrote: > On 16/09/14 16:51, "Mark Gaiser" wrote: > >> On Tue, Sep 16, 2014 at 2:11 PM, Knoll Lars wrote: >>> Hi everybody, >>> >>> I’m happy to tell you that we’re making significant progress towards the >>> new unified web page that I’ve first been talking about at

Re: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation)

On 4-9-2014 18:26, Thiago Macieira wrote: > On Thursday 04 September 2014 13:03:12 Saether Jan-Arve wrote: >> Somebody already suggested to embed it as a resource, isn't that good >> enough? > As long as we also load it by default. We cannot depend on users loading the > translation file from the r

Re: [Development] QOptional

f so, the "Optional" variant doesn't look much simpler than any of the others, even less so when one doesn't accept the use of 'auto' there. > Still, the issue about the semantic of “if(value)” when value == 0 / > false is still a concern (and one of the reason

Re: [Development] QOptional

;auto' in contexts where the type is not obvious to the casual reader. Another can of worms. In practice this would end up often enough with bool ok; const int value = string.toInt(&ok); if (ok) qDebug() << "value is" << value; vs const QOptional value

Re: [Development] QOptional

to chose a different name. > > While I agree that the existing API is not nice, coming up with new names > won't be much nicer. In Qt 6, I we can just use std::optional and similar. In > Qt 5, personally, I'd say lets stick

Re: [Development] QOptional

Иван Комиссаров [abba...@gmail.com] wrote: > The goal is to get rid of ugly "int QString::toInt(bool *ok = 0)" functions. Can you maybe spell out some code to demonstrate why this is ugly, and how the use of QOptional would improve

Re: [Development] QOptional

Иван Комиссаров wrote: > I've started working on a QOptional class > (https://codereview.qt-project.org/#/c/92006/). > As Thiago mentioned in gerrit, there are some things to discuss. 3) Why do we need that class at all? Andre'

Re: [Development] Debugging Android App on Qt Creator 3.1.2 and real device (Python scripting)

on (at least on Linux...) You could install r9d next to your r10 and copy the arm-linux-androideabi/bin/arm-linux-androideabi-gdb and share/gdb to your r10 installation. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

nvert types than to pass through QVariant, I consider the possibility to do type conversion through QVariant a mis-feature, and adding even more conversion abilities would be a step into the wrong direction _for me_. This is a personal opinion. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

B b = a1; A a2 = b; round trip ideally should yield a1 == a2. If I am ready to give up information, I'd like to need to say so in the code explicitly. (And yes, part of the deed is done in the core language, but even there compilers start to nag about it.) Andre'

Re: [Development] Converting types in Qt

Olivier Goffart: > Poenitz Andre wrote: > > I wholeheartedly disagree. Most of my QVariant uses are there because > > the Qt API requires me to use it, and I sometimes use it voluntarily for > > type-agnostic storage or transport of "things". But in those cases I nev

Re: [Development] Converting types in Qt

ng > and nice conversions. I wholeheartedly disagree. Most of my QVariant uses are there because the Qt API requires me to use it, and I sometimes use it voluntarily for type-agnostic storage or transport of "things". But in those cases I never want to extract anything else f

Re: [Development] Converting types in Qt

;s far too easy to make mistakes based on the "nice and easy" QByteArray -> QVariant -> QString conversions when accidentally writing QByteArrays into QSettings and reading QStrings back. There shouldn't be more of that. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Gerrit dropping CI failure mails?

? the process is > supposed to be contributor-driven. Initiated by the contributor, but the actual process is a shared effort. Especially in cases of repeated unrelated CI failures and reviewers and contributor not sharing the same working hours it he

Re: [Development] Gerrit dropping CI failure mails?

orced. > > Is it just me or how much does everybody else rely on it? It's not just you. I pretty much prefer mails in my inbox in case something happens (or fails) over polling a web interface too. I am also mildly surprised that such a workflow defining feature gets deactivated without any discussion. Andre ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] new "debugsupport" module and API

Ulf Hermann: > Is anyone opposed to keeping this in a separate qtdebugsupport.git > repository, then? With what compatibility promises regarding code and protocol? Andre' ___ Development mailing list Development@qt-project.org http

Re: [Development] Modules in qtbase (was: Re: new "debugsupport" module and API)

good reason for code inclusion. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Categorized logging inside Qt

UG looks odd. Your reasoning that it's REPEATED ALL OVER also MAKES ME THINK that USING ALL CAPS might be NO GOOD IDEA as it gives ME the feeling the code is constantly SHOUTING AT ME. Andre' PS: The time such features are contr

Re: [Development] qt_add/removeObject hooks

f[fooIndex])(); // custom now. } Something like that (specifically something that does not need a function call to extract data like qVersion() does) would be very helpful for "normal" debugging, too. Add/removeObject would just be two slots in the array and can be "replaced

Re: [Development] Harmonizing the Qt 5.x Documentation

Matthew Woehlke schreef op 11-3-2014 17:04: > On 2014-03-11 05:01, Pasion Jerome wrote: >> Short summary: We will be redirecting viewers of Qt 5.0 and Qt 5.1 >> documentation >> to "Qt 5" documentation. Subsequently, we will remove the 5.0 and 5.1 >> documentation >> from qt-project.org and we wi

Re: [Development] The Dynamic OpenGL on Windows Change

elps at least at the user visible layer. ("user" in the widest sense: Release team, "developer-users", end users) > This change seems to muddy the waters much more than it helps our end users. Quite the opposite in my opinion. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] On the effectiveness of time based releases

rend, there must be a tight reign on feature development in _all_ modules. Having a centralized "joint API sanity master instance" would definitely be a step into the right direction. It sort of used to work at a time... Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Interest] qmlx11 plugin

"of course" assumes that we can do the same on the other platforms. Having stubs doing nothing/returning something harmless would be easier to handle in such cases for user code than to build special platform dependent packages, integrate with build systems etc. Andre' _

Re: [Development] Build Hotspots in the Qt build process

is that any refactoring there is not worthwhile. > I’m happy to provide a more detailed Qt dataset when I > return to my lab next week. It would be nice to see some reason ("numbers") why files ended up on the list. Best regards, Andre'

Re: [Development] Need suggestion for a new API

Mandeep Sandhu schreef op 31-1-2014 13:47: > Hi All, > > I needed a suggestion on an API I'm adding to QNetworkAccessManager > and co. > > I'm adding a HTTP redirect feature to QNAM. It can be enabled at a > global (QNAM) level, or can be enabled/disabled on a per request > (QNetworkRequest) bas

Re: [Development] Let's get rid of qDebug/qWarning/qCritical!

ct.org/#change,75029 > > Note the patch is fairly ugly because we're gracefully handling the c > ase where the toolchain doesn't respect Q_COMPILER_VARIADIC_MACROS, > I'll post a second mail about this soon ... What about post-poning the whoie idea until we can rely on variadic macros

Re: [Development] Let's get rid of qDebug/qWarning/qCritical!

Koehne Kai wrote: > > -Original Message- > > From: development-bounces+kai.koehne=digia@qt-project.org > > [...] > > As a blueprint I've started a patch for a 'qt.core.io' category: > > > > https://codereview.qt-project.org/#change,74

Re: [Development] Let's get rid of qDebug/qWarning/qCritical!

to worry about, and it would also solve the problem of a "compile time" "null stream": #define qFoo(stream, stuff) /*nothing*/ We had this discussion before. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Coding style proposal

André Somers wrote: > Poenitz Andre schreef op 2-1-2014 23:49: > > Jiergir Ogoerg wrote: > >> Ironically, not even the IDE (QtCreator) sorts them out, in my example > >> parse...() is the 1st in the list, and locale() is the last one (16th). > > There's a

Re: [Development] Coding style proposal

or is to use the Locator facility, i.e. press Ctrl-K to open the Locator, further 'm', to select functions: (independently of the file), or '.', for C++ symbols in the current file. There's no need to guess where a function definition is

Re: [Development] Qt 5.2 RC1 candidate packages available

ould you try to add the '-noload Welcome' command line option when starting Qt Creator and see whether this still crashed immediately? (The option prevents loading of the Qt Quick 2 based Welcome screen, session management would still be available under Files->Sessions/ Files

Re: [Development] #error for unreleased MSVC versions

lable _even for people who do not care about binary compatibility_? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A QtCore class for event-driven jobs

Op 6-9-2013 19:56, Matt Broadstone schreef: On Fri, Sep 6, 2013 at 1:52 PM, David Faure > wrote: I would like to propose the inclusion of a QJob class in QtCore, based on years of experience with KIO::Job and KJob. The idea is to encapsulate an event

Re: [Development] Fwd: Change in qt/qtbase[dev]: Enable -Werror for all of qtbase

or=sign-compare] cc1plus: all warnings being treated as errors Together with the recent insistence that it's fine to submit non-compilable chances I start wondering about the direction. Andre' ___ Development mailing list Development@qt-pr

Re: [Development] New online installers available for testing

Op 31-5-2013 11:50, Heikkinen Jani schreef: Hi all! There is new online installers available in http://download.qt-project.org/online/qt5/online_installers/ At the moment content is Qt5.0.2 but it will be updated to Qt5.1 RC1 w

Re: [Development] Evolving Qt's multithreading API

Op 4-3-2013 21:21, Thiago Macieira schreef: > On segunda-feira, 4 de março de 2013 17.25.35, André Somers wrote: >> QFuture runFunction(QFunction then, QFunction main); >> QFuture runFunction(QFuntion then, QFuntion main); >> QFuture runFunction(QFunction main); > I think this is going too far. If

Re: [Development] Evolving Qt's multithreading API

Op 22-2-2013 11:57, Sze Howe Koh schreef: >> Some more common use case would be (pseudo-code) >> > >> >auto watcher = new QFutureWatcher; >> >QObject::connect(watcher, SIGNAL(finished()), myObject, SLOT(doStuff())); >> >watcher->setFuture(QThrerad::run([]() { return computeStuff(); } )); >> >// who

Re: [Development] Qt Creator Debug - GDB error

: File format not recognised That's the wrong run configuration (the one for the wrapper script, not the application itself). Select 'app', not 'bin' in the Target selector or under Projects/Run Run configuration. Andre' __

Re: [Development] Qt 5.1 feature set and freeze date

Rodal Samuel wrote: >On 02/14/2013 10:39 AM, Poenitz Andre wrote: >> Samuel Rødal wrote: >>> What use is a QPlatformPixmapHandle having per-platform typedefs >>> (xcb_pixmap_t, HDC, etc) without #ifdefs to manipulate it using native >>> code in the first pl

Re: [Development] Qt 5.1 feature set and freeze date

n be defined more cleanly, similarly class interfaces. Ports to new platforms with new platform specific handles are easier as they touch less code. Etc etc. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Hebrew

Op 1-2-2013 17:41, Genghis Khan schreef: > On Fri, 1 Feb 2013 09:26:24 + > Knoll Lars wrote: > >> On Jan 31, 2013, at 4:13 PM, Genghis Khan wrote: >> >>> Hello, >>> >>> I would like to initiate a new group >>> called "Qt Hebrew" for Hebrew speakers, where new an

Re: [Development] Closing Jira Bugs

Op 30-1-2013 21:19, Shaw Andy schreef: > Just to muddy the waters here, but would it be possible to make sure > it only does this when the patch integrates? What happens if the bug > is reopened because it turns out to be still be an issue? Andy That can always happen, even after releasing. I do

Re: [Development] Closing Jira Bugs

Op 30-1-2013 19:34, Robin Burchell schreef: > On Wed, Jan 30, 2013 at 7:05 PM, Sergio Ahumada > wrote: >> How many changes do you need to close a jira task ? one, two, more, who >> knows ? > The person submitting the change. > > The way I've seen this done various other places is to stop trying to

Re: [Development] abandoning stale changes on gerrit

so, the matter is not up for discussion: the cleanup of dead changes > was decided before we launched. i'm just executing. Than this decision should be revised. My dashboard still fits a screen, even with a few old items in it. If yours doesn&

Re: [Development] QAction-like API for QML

Op 12-12-2012 18:35, Stephen Kelly schreef: > On Wednesday, December 12, 2012 09:44:10 André Somers wrote: >> Op 11-12-2012 21:59, Alan Alpert schreef: >>> On Tue, Dec 11, 2012 at 10:49 AM, Shawn Rutledge >>> >>> wrote: On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote: > Why ca

Re: [Development] QMake behaviour change

> Nope, but I guess that a common interpretation of pro-files between > qmake and QtCreator are of interest to most. You need contemporary versions of Qt Creator for use with recent versions of Qt. Andre' ___ Development mailing list Dev

Re: [Development] New mailing list: web_AT_qt-project.org created

Op 26-11-2012 12:12, Verma Gurudutt schreef: Hi I am really happy to inform you all that new mailing list web_AT_qt-project.org is created now. We will be discussing open governance model of web development related stuffs for qt-project.org here and proposal for this was made few days ago

Re: [Development] HEADS UP: Changes in QStyle subclasses

Op 24-11-2012 12:09, Nurmi J-P schreef: Hi all, Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and customize any available style. This is not limited to the built-in styles in QtWidgets, but also works fine for any style plugin since it nicely avoids the build time dep

Re: [Development] binary compatibility promise (was: Re: Frameworks on Mac?)

gt; > self-inflicted pain without measurable gain. > > This situation is different on mobile (and I guess embedded as well); > for BlackBerry10 we have one version of Qt on the device Do you intend to upgrade this version of Qt that's installed on the device without upgrading the

Re: [Development] Pending decisions on co-installation

of a handful of Linux distribution packagers - half which will do their own renaming anyway, no matter what the official solution will look like. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

could then be: "write qmake5 to build Qt 5 things" Users/Admins could then use the distribution's "defaults" system to switch the "system" Qt version, they can also override the system setup by modifying their local PATH settings, per-shell even. None of

Re: [Development] Summary of renaming changes

decision is "stay put". In the other case, someone has to cleanup the fallout. Neither tooling nor user projects will magically adjust just because there was a Word. Andre' PS: I honestly start wondering how a change with such an impact can be seriously considered _at all_ that l

Re: [Development] Summary of renaming changes

ng a code base running on both Qt 4 and Qt 5, and even hampering a direct Qt 4 -> Qt 5 port. * Documentation needs to be adjusted. * Existing third party documentation of Qt in use, howto's, tutorials, in the *net lose value, because it will be not accurate anymore. This is a completely unreasonable trade-off. Andre' Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branching for Qt 5 repositories

contain without consulting "external" documentation. Also, since "master" has been used in the past, re-using it for a different(!) level will cause confusion, as people will run into outdated information all over the net. Andre'

Re: [Development] QFileSystemWatcher and Recursive Monitoring

Op 28-7-2012 11:04, d3fault schreef: > > I've been thinking about it some more, and I think it would be a good > idea to add another optional bool to the opt-in custom interface > constructor. > Having (series of) bools in API's is usually a bad idea. See for instance this blog posting: http://

Re: [Development] Abandoning the container changes

Op 16-7-2012 23:52, Thiago Macieira schreef: > On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: >> On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: >>> Hello all >>> >>> I think that, despite the potential benefits of the changes, we >>> should not apply them at t

Re: [Development] Notes from the QWidget session

Op 27-6-2012 22:17, Иван Комиссаров schreef: > Hm... What about adding new (maybe rather simple) widgets? QtCreator has > QtColorButton class, QtFontButton, lineedit for editing shortcuts (i have my > own modified copy). > Browser example has ModelMenu and ModelToolBar classes (rather useful in s

Re: [Development] Qt Summit 2012 Registration is now open!

Op 14-4-2012 12:08, Sivan Greenberg schreef: > On Fri, Apr 13, 2012 at 8:57 PM, Quim Gil wrote: >> Still "a third party" from a Qt Project point of view but I guess one >> that you are more used to trust. Sorry, it was the fastest and simplest >> way to save us from handling emails manually. > Who

Re: [Development] Dropping the Q prefix from class names

Op 2-4-2012 1:02, joao.abeca...@nokia.com schreef: Hello again, To every-concerned-one-of-you, I hope you do realize that we share all of those same concerns. We do! :-) I really enjoyed this joke. Thanks! :-D André ___ Development mailing list Dev

Re: [Development] QDoc can't ignore Q_PROPERTY

Op 9-3-2012 23:22, casper.vandonde...@nokia.com schreef: > Just to make sure everybody understands: > With this change applied all NOTIFY properties that are currently documented > will not be documented anymore. > > If there are no objections before coming Tuesday (13 March) 09:00 Oslo time I >

Re: [Development] videoPlayer crashed

Hi Brian, 1) It is rude to hijack somebody elses thread. The thread you are replying in is about a request for a UI Helpers repository, not about Phonon. 2) You're in the wrong mailing list. This list deals with developing Qt *itself*, not with developing *with* Qt. You are looking for the inter..

Re: [Development] RFC: The Future of QDoc

Op 10-2-2012 8:07, Andre Somers schreef: > Op 9-2-2012 19:13, marius.storm-ol...@nokia.com schreef: >> On 09/02/2012 10:33, ext Manuel Nickschas wrote: >>> On Thursday 09 February 2012 15:36:09 ext Olivier Goffart wrote: >>>>> I am working on QDoc part-time

Re: [Development] RFC: The Future of QDoc

Op 9-2-2012 19:13, marius.storm-ol...@nokia.com schreef: > On 09/02/2012 10:33, ext Manuel Nickschas wrote: >> On Thursday 09 February 2012 15:36:09 ext Olivier Goffart wrote: I am working on QDoc part-time and we have been discussing some changes that we would like to implement to make q

Re: [Development] Qt Contributors Summit: when and where

Op 3-1-2012 21:14, Richard Moore schreef: >>> - How many rooms, which capacity? No need to get into details but having >>> a rough idea would be useful in order to book the right amount of space. >>> For you this means what type of event do you want: was the event last >>> year good or would you pr

Re: [Development] Qt Contributors Summit: when and where

Op 3-1-2012 19:48, marius.storm-ol...@nokia.com schreef: > On 03/01/2012 12:25, ext Jonas M. Gastal wrote: >> On Tuesday 03 January 2012 18:11:08 marius.storm-ol...@nokia.com >> wrote: >>> On 03/01/2012 11:14, ext Quim Gil wrote: - When? There have been different opinions and the trend seems t

Re: [Development] QRegularExpression -- first round of API review

Op 16-12-2011 1:07, Giuseppe D'Angelo schreef: > >> fwiw, the usual elegant solution is having a value and a mask parameter. >> the mask could have two magic values meaning "un-/set all asserted in >> vlaue" to mean effectively what your bool means. the default argument >> would be the magic value

Re: [Development] Json support for QtCore

Op 11-12-2011 15:55, lars.kn...@nokia.com schreef: > The binary representation is optimized for fast reading. The binary > format > is relatively compact and stores the whole object in one blob. >> Is this a standard binary format of JSON, or something of your own devise? > It's something I wrote.

Re: [Development] This week in Qt 5 development (week 49)

Op 9-12-2011 20:18, Stephen Kelly schreef: On Friday, December 09, 2011 20:12:05 Stephen Kelly wrote: > This week: > Oops, sorry. This was not intended for the Qt mailing list. I was compiling it for colleages. Aren't we all, in a way? ;-) Anyway, thanks. I think it is informative! André

Re: [Development] Moving itemmodels classes to QtCore

Op 23-11-2011 14:52, shane.kea...@accenture.com schreef: Hi, I think moving the item models back into QtGui would be better than QtCore. * QML and Widgets applications both depend on QtGui * The item models have no use outside of a GUI application. * QtGui was the location of these classes

Re: [Development] QTemporaryDir API

Op 16-11-2011 18:56, David Faure schreef: > On Wednesday 16 November 2011 18:26:25 Andre Somers wrote: >> Op 16-11-2011 18:13, David Faure schreef: >>> Hello, >>> >>> As previously discussed on qt5-feedback, I wrote QTemporaryDir and >>> submitted it

Re: [Development] QTemporaryDir API

Op 16-11-2011 18:13, David Faure schreef: > Hello, > > As previously discussed on qt5-feedback, I wrote QTemporaryDir and submitted > it to gerrit at http://codereview.qt-project.org/#change,8297 > After a few reviews from Thiago (and redoing the implementation on Windows) > it's now ready for subm

Re: [Development] API review for a new QDnsResolver class

Op 9-11-2011 19:35, Jeremy Lainé schreef: > On 11/09/2011 07:21 PM, Peter Hartmann wrote: >> On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote: >>> (...) >>> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString); >>> >>> pro: easy to connect to the QDnsReply's signal >>> con: it's entirely

Re: [Development] API review for a new QDnsResolver class

Op 4-11-2011 20:31, Jeremy Lainé schreef: > On 11/04/2011 10:15 AM, André Somers wrote: >> The more I think about it, the more I think it is important to fix this: who >> is >> responsible for the lifetime of the QDnsReply object? >> > Why not have the same pattern as QNAM for consistency? How abo

  1   2   >