On Mon, Oct 10, 2022, at 12:11 PM, Hasselmann Mathias wrote:
> I am surprised by the question: "It's non-standard and it's behavior is
> undefined" actually should be enough to avoid such feature.
I suggest that you don't look at the implementation of things like Q_OFFSETOF,
then. ;-)
// This m
On Thu, Nov 25, 2021, at 7:43 PM, Thiago Macieira wrote:
> On Thursday, 25 November 2021 09:21:58 MST Marius Kittler wrote:
> > > I don't need deployment from Linux in order to develop and it looks like
> > > people who have been using cross-compilation have worked around this
> > > issue.
> >
> >
On Wed, May 19, 2021, at 8:16 PM, Giuseppe D'Angelo via Development wrote:
> * there's no registration required;
> * the $newthing has proven stability, staff, resources, etc., and won't
> disappear in a few months/years;
> * ...
>
> then anything is fine.
>
> All other things being equal, the
On Mon, Jan 4, 2021, at 2:13 PM, Oswald Buddenhagen wrote:
> https://bugreports.qt.io/browse/QTQAINFRA-4121 for anyone interested in
> the inevitable community fork.
FWIW, I created https://github.com/qt-lts-community a while ago in preparation
for this (though I did not think much of this, TBH,
On Mon, Jan 27, 2020, at 11:15 PM, Cristián Maureira-Fredes wrote:
> This means that you still have access to all the fixes for 5.15
> that happen after 5.15.2-3, since they will be on the dev branch.
>
(...)
>
> If there is a bug on 5.15 and not on 6.0,
> a fix will be pushed to the dev branch,
On Tuesday 12 June 2018 00:41:38 Thiago Macieira wrote:
> On Monday, 11 June 2018 22:50:09 CEST Rafael Roquetto wrote:
> > Would it also make sense to explore msgpack? https://msgpack.org/
>
> No. Msgpack is the older version of CBOR, which we already have.
CBOR is IMHO better than Message Pack,
On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote:
> In that case, the QCoapReply life is managed with a
> QSharedPointer in the request.
>
> QCoapRequest does not inherit from QObject. Anyone sees a problem with this
> approach?
The API sounds interesting, but it's a departure of what we a
On Saturday 02 December 2017 19:11:23 Boudewijn Rempt wrote:
> > > And, c'mon, std::optional's API is just not going to be topped by
> > > QOptional. What should they do? snake_case vs. camelCase? That's what
> > > we need to invest several man-days of development work in, to rename
> > > the funct
On Saturday 22 July 2017 18:51:28 Phil Bouchard wrote:
> You're probably making a living off memory leaks so it's obvious you get
> offended but I don't think being a counterproductive manager is good for
> the Qt company. In fact it's the first time ever I hear about a manager
> complaining abo
On Wednesday 26 April 2017 07:02:49 Marc Mutz wrote:
> FWIW: I'm against adding even more pessimising goodies to QVector. An
> area for push_front is such a goodie. The addition this causes is
> probably the reason why a QList, even for optimal payloads, is
> outperformed by QVector in my well-k
On Tuesday 25 April 2017 16:35:01 Thiago Macieira wrote:
> QVector and QList don't have the same API. They're slightly different.
> What'sm ore, QList has a beginning-of-list optimisation, whereas QVector
> doesn't (not even my copy, I stopped development shortly before I got to
> that part, even
On Monday 17 April 2017 03:25:49 Jason H wrote:
> I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point,
> etc]) don't use an interface? I recently moved some code from ints to
> floats, and I had to change far more code than I should have had to.
>
> My proposal is to change QRe
On Thursday 13 April 2017 21:02:59 Randall O'Reilly wrote:
> This also means that there is an endless potential for language wars, which
> I’m sure nobody wants to rehash on this list.
Are you sure? Because in the next sentences seem like you exactly started to
fight for one side. You said that C
On Wednesday 29 March 2017 20:11:58 Marc Mutz wrote:
> I would really, really
> like to know why QVector is easier to use? Because it has indexOf()?
> Seriously, now?
Because it has _lots_ of easy to use member functions, and another kind of
iterator that is also easier to use for some, and goo
On Friday 27 January 2017 15:48:54 Sean Harmer wrote:
> Obviously putting these directly in the qt3d repo is not ideal yet we need
> examples to demonstrate this stuff (and more in the future). Is there a way
> we can get a git-lfs repo set up as a submodule to be referenced by the
> qt3d repo?
>
On Saturday 19 November 2016 21:08:00 Kevin Kofler wrote:
> I am glad that I am not alone with that feeling.
>
> And by the way, with my distribution packager hat on, I have to frown upon
> the idea of dragging in yet another dependency just to enforce the C++
> language inventor's personal, not u
On Sunday 26 June 2016 23:20:41 Alejandro Exojo wrote:
> This just makes me wonder a bunch of things:
Sorry, I wanted to trash this email that I started to write last Friday, and
instead I sent it. This reads harsher that what I wanted to send, and I did
not want to add more noise.
My point
On Wednesday 22 June 2016 05:29:35 Simon Hausmann wrote:
> Approach 3: Include the one declarative fix in 5.6.1, create a new tag and
> rebuild declarative and all the modules that depend on it. That is the
> quickest way of getting the release into the hands of the users (qtbase was
> not rebuilt
El Tuesday 26 April 2016, Shawn Rutledge escribió:
> Personally I think event compression should be a cross-platform feature if
> we’re going to have it. The event-pileup problem can happen also on
> Windows for example, but it seems that we never implemented event
> compression on any platform ot
El Saturday 02 January 2016, Martin Koller escribió:
> ... and I hope this is not the final plan (using QTextBrowser instead of a
> real HTML engine), since then our help pages (we integrated assistant into
> our product) would no longer render correctly.
>From the commit message that I've linked
El Saturday 02 January 2016, Aleix Pol escribió:
> Hi,
> One of the big news lately is the deprecation of Qt WebKit module.
>
> One of the Qt dependencies on it is assistant (which is a tool I use
> quite often, really) and AFAIK it's using it quite thoroughly. It used
> to be powered by QTextBrow
El Sunday 27 December 2015, Kevin Kofler escribió:
> I consider the C declarator syntax just fine, it is very intuitive and has
> served us well for 26 years, so I don't see a need to change it.
That some things have served up well for some time, that doesn't mean we can't
find better things (ei
El Friday 27 November 2015, Bauer, Christian escribió:
> Our (simplified) problem is: this function does not return a value but
> feeds an asynchronous pipeline. When the pipeline processing is done it
> will call promise.SetResult(); promise.reportResult();
> and only then the future should be not
El Thursday 03 December 2015, Mark De Wit escribió:
> Building from source would be an option, I guess. We have done it in the
> past, but the build process / flags (for distribution) is not sufficiently
> well documented, and starting with 5.5.1 we were excited to be able to use
> official binari
El Saturday 10 October 2015, anton escribió:
> Hi,
>
> only a small question.
Hello. Please note that this mailing list is for development of Qt itself, not
for asking questions about Qt. Use the "interest" mailing list next time,
please.
> I wanted to give QT 5.5.0 a try,
> and started a new
El Sunday 12 July 2015, Thiago Macieira escribió:
> On Sunday 12 July 2015 16:16:07 Smith Martin wrote:
> > I can see by your explanation that QVector is almost always more
> > efficient than QList. But sometimes the difference doesn't matter.
>
> If it doesn't, then why not choose QVector?
I've
El Sunday 12 July 2015, Marc Mutz escribió:
> On Sunday 12 July 2015 13:11:54 Smith Martin wrote:
> > And yet you wrote a blog about it instead of submitting the info to us to
> > update the QList documentation. Currently, the QList page says this:
> >
> > "QList, QLinkedList, and QVector provide
El Tuesday 30 June 2015, Ansel Sermersheim escribió:
> Our September release of CopperSpice will include changes to the
> contain library, reimplementation of atomic types, our new changes to
> the MetaObject System registration, full API documentation, ??
>
> We would like to encourage developers
El Monday 18 May 2015, Smith Martin escribió:
> You omitted that toInt(&ok) is required to test ok for null, which is not
> required if ok is a reference.
That's extra work in the implementation in order support a nicer API to the
users, e.g. to support toInt() with the null value as default argu
El Friday 01 May 2015, Dmitry Volosnykh escribió:
> Diff of the patch and example of CustomKeys QML attached type may be viewed
> here: https://gist.github.com/dvolosnykh/65819bca1693b0e82058
You should follow the formal procedure, which is submitting it through Gerrit:
http://wiki.qt.io/Qt_Contr
El Friday 20 February 2015, Tomasz Siekierda escribió:
> On 20 February 2015 at 12:52, Alejandro Exojo wrote:
> > El Thursday 19 February 2015, Tomasz Siekierda escribió:
> >> So those companies/ users of QNX are not willing to upgrade their OS,
> >> compiler, but the
El Thursday 19 February 2015, Tomasz Siekierda escribió:
> So those companies/ users of QNX are not willing to upgrade their OS,
> compiler, but they are willing to upgrade Qt?
I think the main problem with requiring a very up to date Qt is that sometimes
only newer versions of Qt have bugfixes.
El Friday 20 February 2015, André Somers escribió:
> Olivier Goffart schreef op 20-2-2015 om 11:38:
> > On Friday 20 February 2015 11:26:31 Daniel Teske wrote:
> > [...]
> >
> >> That's one area. The others are too replace trivial interfaces with a
> >> low amount of virtual functions by a std::fu
El Sunday 15 February 2015, Sune Vuorela escribió:
> On 2015-02-15, Alejandro Exojo wrote:
> > People might rely on the function in proprietary applications in ways
> > that are impossible to predict.
>
> Every time we fix a bug, we might introduce regressions for people
El Thursday 05 February 2015, Thiago Macieira escribió:
> On Thursday 05 February 2015 11:07:29 Koehne Kai wrote:
> > It's not used anymore in the evaluation process, AFAICT. I wouldn't mind
> > deprecating it ...
>
> Then change it to 2012-12-20.
Isn't this just breaking the function, and markin
El Friday 06 February 2015, André Somers escribió:
> All the while Qt is spending effort to catch up, deprecating compilers
> and platforms because they can't take the latest Javascript engine to
> it, users are hapily using browers like Firefox and Chrome.
>
> Perhaps it is time to conclude tha
El Tuesday 09 December 2014, Dmitry Volosnykh escribió:
> Hi!
>
> "What's New in Qt 5" documentation article
> (http://qt-project.org/doc/qt-5/qt5-intro.html) under
> "Designing UI Made Simpler" section introduces Qt Quick Controls and
> Qt Quick Layouts modules at once. As far as I can see there
El Thursday 20 November 2014, Alejandro Exojo escribió:
> El Wednesday 19 November 2014, Thiago Macieira escribió:
> > On Tuesday 18 November 2014 16:24:05 Thiago Macieira wrote:
> > > On Tuesday 18 November 2014 16:38:55 Frederik Gladhorn wrote:
> > Attached the w
El Wednesday 19 November 2014, Thiago Macieira escribió:
> On Tuesday 18 November 2014 16:24:05 Thiago Macieira wrote:
> > On Tuesday 18 November 2014 16:38:55 Frederik Gladhorn wrote:
> Attached the wrong file.
Probably irrelevant, but, on which branch was the script run? On both 5.4.0
and 5.4 (
El Monday 10 November 2014, Robert Steckroth escribió:
> [SOLVED]: After perusing the qmap.h libraiy I found the reason why QMap was
> keeping a sorted node list.
Please, instead of opening bug reports, digging in the sources, and wasting
everybody's time, you should read one of the very first li
El Friday 24 October 2014, jiaojinxing1...@gmail.com escribió:
> Now the latest qt 4.8 6 run on sylixos is very stable,
>
> And supports advanced features such qws and webkit.
> We are willing to contribute our code to qt organization.
That's great, but note that Qt 4 is feature frozen. I don't
El Tuesday 07 October 2014, Tomasz Siekierda escribió:
> For file paths, I feel QString is really enough.
> Changing it to something else because of a few corner cases seems like
> an overkill to me.
Just for the sake of documenting the issue and pointing to this thread if
future questions arise:
El Monday 25 August 2014, Blasche Alexander escribió:
> Hi,
>
> It is my understanding that the current Linux release binary packages are
> built on Ubuntu 11.10 machines. This is very ancient. In fact for
> Bluetooth Low Energy (new feature in 5.4) this is too ancient.
The reason to use an old
El Friday 11 July 2014, Thiago Macieira escribió:
> On Friday 11 July 2014 00:17:48 Alejandro Exojo wrote:
> > Logging to the console _and_ journald has proven very useful to us. We
> > did it specifically for an application using Qt's API, and developers
> > can code, p
El Friday 11 July 2014, Lisandro Damián Nicanor Pérez Meyer escribió:
> AFAIU from this thread, journald support should not be enabled except
> "regular users can read the output". Now what I'm missing here is: if Qt
> is built with journald support, can it be still be used if journald is not
> pr
El Thursday 10 July 2014, Koehne Kai escribió:
> Provide a define QT_LOG_TO_CONSOLE that let QCoreApplication.h record
> whether it should log to console (QT_LOG_TO_CONSOLE=1), to the system
> (QT_LOG_TO_CONSOLE=0), or both (QT_LOG_TO_CONSOLE=2).
Would it be too problematic to make the environme
El Wednesday 09 July 2014, Thiago Macieira escribió:
> === Log to both ===
> Aside from the extra overhead, this causes systems that capture both stderr
> and the system log to record and display the same message twice. That's the
> source of task [3].
>
> This is not an option.
Why not? Task [3]
El Wednesday 04 June 2014, Olivier Goffart escribió:
> Where is it? Do you have any URL?
He replied to my privately (by mistake I suppose) saying it was on github, so
after a search:
https://github.com/u19809/DynamicQObject
--
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http
El Monday 02 June 2014, wim delvaux escribió:
> I tried using gerrit but this is very tedious (setting up GIT, getting
> access to Qt code, downloading lost of 'git' code which is not needed, etc)
> I find this unnecessary as my extension compiles just like a simple Qt
> Project
(...)
> I would li
El Saturday 21 December 2013, Kurt Pattyn escribió:
> Qt currently supports the following ‘severity’ levels for logging: Debug,
> Warning, Critical, Fatal and System.
>
> I propose to add the following levels: Info and Error, with associated
> methods qInfo() and qError(). Particularly, the Info s
El Martes, 22 de octubre de 2013, Knoll Lars escribió:
> So much for Linux distributions keeping binary compatibility.
Isn't exactly the same situation as with Qt? When the "next version of Qt 4.8"
breaks binary compatibility, libqt5 is introduced. You link against either one
or the other, and g
Hi.
I've stumbled upon the names of the classes in Qt Android Extras:
- QJNIEnvironment
- QJNIObject
The all capital part due to the acronym is inconsistent with other Qt classes,
where the acronym is written as if it were a word: e.g. QHttp* instead of
QHTTP*, QUrl instead of QURL, etc.
I've
52 matches
Mail list logo
