Hi all!
I've recently bumped into an issue on AuroraOS (a fork of
SailfishOS), where as soon as an application window gets created, the
output gets filled with logs similar to these, and the application gets
stuck:
[W] unknown:230 - qrc:/Sailfish/Silica/private/TabBar.qml:230:5: QML
Hi Fabian,
On 02/05/22 09:52, Fabian Kosmale wrote:
I think your issue might be QTBUG-91390 (ListModel does not keep
objects with JS ownership alive in 5.15). That was fixed in Qt 6.2
(https://codereview.qt-project.org/c/qt/qtdeclarative/+/354140), but
due to the behaviour change never
Hi Furkan,
On 01/05/22 20:01, Furkan Üzümcü wrote:
I think adding an object to a `ListModel` does not alter its
ownership. If the page with the initial property which holds a
reference to the object returned from the C++ method is destroyed,
then I would expect that object to be destroyed as
Hi there!
I think I'm experiencing an issue related to
https://bugreports.qt.io/browse/QTBUG-50319
In my case, I have a C++ method returning a new QObject, which has
automatic Javascript ownership. This is fine, because indeed I want to
have my object managed by the QML engine.
Then I'm
On 06/03/22 16:23, Konstantin Ritt wrote:
For those who have experienced inconvenience due to these blockings, I
propose to gather at some public site and create binaries repo driven by
community, not by political influences.
Sorry for jumping in so late. Please count me in.
My problem is
On 06/03/22 17:07, coroberti wrote:
There are KDE repos, aren't there?
For example:
https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15
The source code, as far as I can tell, it's not the problem. The problem
is with the binary releases, and I cannot find them in the KDE site.
Ciao,
Hi Lars,
On 13/12/21 11:14, Lars Knoll wrote:
>> When the new QtMultimedia was announced [1], there was a mention that
>> the Radio API was being removed (by the way, there is no mention of this
>> removal in the migration document [2]). Did it happen because of a lack
>> of time, or were there
Hi all!
When the new QtMultimedia was announced [1], there was a mention that
the Radio API was being removed (by the way, there is no mention of this
removal in the migration document [2]). Did it happen because of a lack
of time, or were there other reasons? Is it going to come back?
I also
Hi!
I know I'm coming too late with this, but maybe it's something that
can be considered as for future developments of the voting bot:
On 04/10/21 13:08, Daniel Smith wrote:
> If anyone wishes to verify that their personal vote has been recorded
> correctly, they can email
On 13/09/21 21:58, Elvis Stansvik wrote:
> I don't see what's inherently wrong with a plain function like
> Qt.resolvedUrl. It's very obvious - it says what it does on the tin.
> Names are good that way.
FWIW I've been using it for ages, and yes, if it initially it sounded a
bit verbose, now I'm
On 28/05/21 11:09, Lars Knoll wrote:
> Before we go into the topics below, can we take a step back, please? I’d
> first like to know *why* you were developing and maintaining your own
> multimedia backend.
In short, because of lifecycle. In Ubuntu Touch, applications are
stopped when in the
Hi Lars,
On 26/05/21 15:09, Lars Knoll wrote:
> The hope is that we can change that for Qt 6. To make this possible, we have
> changed not only parts of the public API, but completely redone its internal
> architecture, especially how multimedia connects to the platform specific
> backends.
On 27/05/21 11:50, Giuseppe D'Angelo via Development wrote:
> In the overwhelming majority of cases, utf16() won't make any
> allocation. There's just one exception -- if the QString was built via
> fromRawData(). In that case, in order to ensure NUL termination, utf16()
> does actually "detach"
On 26/05/21 23:31, Christian Ehrlicher wrote:
> Your observation looks correct even though I wonder why this was never
> found before since this was not changed since the initial Qt5 import :)
> What Qt version do you use?
> Please fill a bug report with a minimal, compilable example.
I'm using
Hi there!
I'm encountering some sort of memory corruption issue in a library I'm
using, which does not cause a crash, but rather a QSQLite query to
sometimes simply return no results, without errors or warnings.
You can find the valgrind trace here:
Hi Tiago,
On 08/05/21 18:47, Thiago Macieira wrote:
> And the problem is that they *do* depend on the CPU architecture. long
> changes
> size depending on OS and pointer size.
yes, I knew that long changes size depending on the architecture, but:
> As far as I am concerned, the fact that
>
On 08/05/21 10:48, Alberto Mardegan wrote:
> Interestingly, I'm seeing this on amd64 only; it seems that on armhf
> everything is working fine. Could it be a bug with the compiler?
In armhf, QMetaType::type("int64_t") always returns 4 (LongLong), even
before registering the
Hi there!
I'm struggling to understand what's going on with types being
marshalled onto D-Bus, and I'd like to understand if what I'm seeing is
a but with the Qt version I'm using (Qt 5.12.7 + some patches), an issue
with the compiler, or just the expected behaviour.
The problem is that QtDBus
On 21/06/20 19:13, Thiago Macieira wrote:
> A set of patches were dropped from the middle of the series, implementing the
> vfork I mentioned. So the patch needs to be rebased and adjusted. Other than
> that, it's fine.
Let's try:
https://codereview.qt-project.org/c/qt/qtbase/+/305791/1
Ciao,
On 20/06/20 23:45, Thiago Macieira wrote:
> No, because it won't catch this:
>
> class MyProcess : QProcess
> {
> protected:
> virtual void setupChildProcess();
> };
>
> Note the lack of Q_OBJECT.
But what is the harm if we don't catch that? It's still better than a
crash, isn't it?
Also,
On 20/06/20 21:42, Konstantin Tokarev wrote:
> Comparing metaObject() with staticMetaObject() is wrong because it would fail
> even for QProcess.
No, I tried, it seems to work as expected:
==
#include
#include
class BaseClass: public QObject {
Q_OBJECT
};
class
On 20/06/20 22:21, Alexey Minnekhanov wrote:
>
> сб, 20 июн. 2020 г. в 22:01, Alberto Mardegan
> mailto:ma...@users.sourceforge.net>>:
>
> we only want to know if we are a subclass of QProcess.
>
> QObject::inherits(..) ?
Sorry, my wording was imprecise: we wan
On 20/06/20 21:42, Konstantin Tokarev wrote:
> Comparing metaObject() with staticMetaObject() is wrong because it would fail
> even for QProcess.
I didn't try, but why would it fail?
> OTOH, using qobject_cast would handle classes derived
> from QProcess correctly, unlike code with typeid().
Hi all!
A couple of days ago a bug was filed against a project of mine, which
has been built with -fno-rtti since Qt4 times:
https://bugzilla.opensuse.org/show_bug.cgi?id=1172904
The bug, it appears, is a crash in QProcess due to the use of typeid(),
which was introduced in Qt 5.15:
On 23/04/20 14:57, Ville Voutilainen wrote:
> QVector is certainly closer to std::vector than QList is to std::list.
> Vector isn't a really good name either,
> for people recently taught in elementary school math, or for java
> programmers coming in.
> For C++ programmers, it gives a much better
end on QtPIM at the moment. Alberto
> Mardegan has done a lot of work in the QtPIM area previously, and might
> be a good candidate if his commitments allow...
I'm certainly willing to help, even though I'm not sure about how much
"significant time" is needed. On the other ha
On 12/02/20 15:20, Vitaly Fanaskov wrote:
>> AFAIK, we don't have a procedure to make project-level decisions by majority
>> vote.
> True. We're discussing now. The goal here is to take people opinions and
> arguments into account before making a decision.
The problem I see, is that in your
On 04/02/20 16:55, Vitaly Fanaskov wrote:
> But if you see API like this:
>
> std::unique_ptr someAPI();
>
> You have much more information about managed object just by reading the
> code. This is also much easier to understand what can or cannot be done
> with the returned value in the
Going back to the original question again, as I'm not sure I agree with
this claim:
On 31/01/20 13:07, Vitaly Fanaskov wrote:
> Smart pointers are for sure much better to use than raw pointers for
> many reasons. They manage lifetime automatically, show ownership
> semantic, and make code
On 03/02/20 19:56, Jason H wrote:
> [...] As a result, the code of a Qt-using program
> should be readable by average developers not big into C++.
[...]
I agree with all what you said; I'm just quoting this sentence because
it's easy to underestimate this.
Ciao,
Alberto
--
On 02/02/20 21:55, Giuseppe D'Angelo via Development wrote:
> On 02/02/2020 17:38, Alberto Mardegan wrote:
>> Believe it or not :-) I find std::shared_ptr easier to use when passing
>> pointers to and from functions. And I never needed to put them into an
>> array.
>
>
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 my work experience, when I'm
>> not allowed to use Qt and am restricted to the STL, all the times I had
>> to use std::
On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote:
> Il 01/02/20 12:44, Alberto Mardegan ha scritto:
>> On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote:
>>> About QUniquePointer: what's the point of reinventing std::unique_ptr
>>> under a differe
On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote:
> About QUniquePointer: what's the point of reinventing std::unique_ptr
> under a different name?
A Qt-ish API!
> * Is it just going to be an alias, to be more Qtish? Then why
> QSharedPointer is NOT going to be an alias?
>
> * Is it
On 31/01/20 23:04, Ville Voutilainen wrote:
> On Fri, 31 Jan 2020 at 21:23, Alberto Mardegan
>>
>> I still have trouble understanding why std::unique_ptr is called like
>> this, whereas I could immediately understand what QScopedPointer does
>> even before reading i
Old man here:
On 31/01/20 13:07, Vitaly Fanaskov wrote:
> But how to use them in the API and which way is preferable is still
> unclear. There are two main options we have:
>
> 1) Use std::* smart pointers as-is.
>
> 2) Add Qt-style wrappers around std::* smart pointers and move old
>
On 29/01/20 19:02, Volker Hilsheimer wrote:
> You obviously don’t trust that TQtC will treat the data the online-installer
> either demands or requires with the appropriate confidence. So, shouldn't you
> build Qt from sources? Your IP address is PII, after all. Why did you trust
> that The Qt
On 29/01/20 13:02, Edward Welbourne wrote:
> Clarification: we'll be moving to "all commits land first on dev and are
> cherry-picked out to other branches that need them" in place of our
> present merge-based module. Where Cristián says "all those patches will
> be on Gerrit", they'll be on dev
On 27/01/20 17:34, Lars Knoll wrote:
> 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 .
[...]
> None of these changes should affect how Qt is being developed. There won’t be
> any changes to
On 20/12/19 13:47, Giuseppe D'Angelo via Development wrote:
> Just to be devil's advocate, there is... As much as it's fun and
> everything implementing a container, just using std::unordered_map would
> have minimal effort on our side ("someone else's problem", and it's not
> even a random 3rd
On 27/06/19 14:14, Bastiaan Veelo wrote:
>
> However, it seems that most web browsers that implemented their own
> browser tech have ditched those in favour of a third party framework
> (see Opera, Edge, e.g.) -- how much of the reason for that is due to
> rendering or networking I don't know.
I
On 27/06/19 04:47, Lars Knoll wrote:
>
> Yes, Webengine uses some memory. But is that really a problem on developer
> machines?
Yes. The more RAM you use for surfing documentation, the less RAM you
have for building. I have 16 GB of RAM, and sometimes I have to close
Chromium away (yes, I know,
On 18/06/19 10:43, Mutz, Marc via Development wrote:
> On 2019-06-18 08:18, Alberto Mardegan wrote:
>>
>> Adding a const bool operator to QSharedDataPointer would solve the
>> problem, wouldn't it?
>
> And (silently) break code that relies on the current behavio
On 05/06/19 01:39, Kevin Kofler wrote:
> Mutz, Marc via Development wrote:
>
>> and produces surprises such as
>> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=96dc9a19ae11ca140d681f0e2605b5f4b953e581
>
> My existing QSharedDataPointer code always checks truth with
> if
On 5/31/19 4:24 PM, Volker Hilsheimer wrote:
> Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with
> three years maintenance. We are not expecting lots of people to jump
> on Qt 6.0 anyway (because .0, and not an LTS release anyway), so when
> an API was marked as deprecated makes
On 30/05/19 18:34, Giuseppe D'Angelo via Development wrote:
> Hi,
>
> On 30/05/2019 10:23, Alberto Mardegan wrote:
>> I bet it's unused because everyone is using QList. But once we deprecate
>> QList, people will start asking for a CoW version of std::list.
>
> QList
On 30/05/19 11:40, Mutz, Marc wrote:
> On 2019-05-30 10:23, Alberto Mardegan wrote:
>> It's not clear to me why splice() cannot be implemented: it would just
>> mean that the list data would detach as in all other non-const methods.
>> Or am I missing something?
>
> Y
On 29/05/19 13:53, Mutz, Marc via Development wrote:
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
>
> These are basically Qt-internals, and should never have been public in
> the first place. It's _because_ they are public that we have two of
> them, and soon a third one (properly
On 18/03/19 12:11, Pierre-Yves Siret wrote:
> This can be done with QQmlFileSelector :
>
> QQmlApplicationEngine engine;
> QQmlFileSelector* qmlFileSelector = QQmlFileSelector::get();
>
> #if QT_VERSION >= QT_VERSION_CHECK(5, 12, 0)
> qmlFileSelector->setExtraSelectors({"5.12"});
>
Hi there!
When developing a QML module for the greater public one wants to
provide a source package that can be built on multiple Qt versions.
However, QML's lack of a preprocessor makes this rather cumbersome.
Suppose that my module needs to provide an element like this:
import QtQuick
On 25/02/19 15:57, Mitch Curtis wrote:
> My only issue with it is that I don't know if it will see much use
> outside of your use case. Usually if all items in a layout have the
> same margins, you would just apply those margins to the layout
> managing them instead. While I appreciate that that
On 25/02/19 11:23, Mitch Curtis wrote:
> So would it look something like this?
>
> // implicit size is 118 x 64
> ColumnLayout {
> defaultLeftMargin: 12
> defaultRightMargin: 12
> defaultBottomMargin: 12
> defaultTopMargin: 12
>
> // implicit size
Hi there!
I'm working on a desktop style for QtQuick.Controls 2 [1], and I'm
currently investigating the issue of layouts. My current approach is to
define my own ColumnLayout element like this:
==
import QtQuick.Layouts 1.2
import it.mardy.Desktop.private 1.0
ColumnLayout {
Hi all!
Speaking of coding style again, I haven't found any indication in the
coding guidelines about brace vs parentheses in initializations.
There are a few cases where they can be used (and I might even be
forgetting some):
1) Constructors:
MyClass(): var(0) {}
vs
On 22/01/2018 18:49, Konstantin Tokarev wrote:
> From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable
> is required to use native backend.
>
> [1] https://codereview.qt-project.org/#/c/162337/
Yes, but still QtWebEngine is required, as QtWebView is linking to it.
I've now
Hi all!
I've developed a desktop application which uses the WebView QML
module, with the hope of publishing it in the Apple store. However,
unless I am seriously mistaken, this is just not possible (or maybe the
documentation needs some serious love).
No matter what I try, it seems that
On 29/10/2017 22:45, Thiago Macieira wrote:
> I wish I could help in the reviews, but those are not things I understand at
> all. But I can give this advice: the three changes targetting pre-5.9 need to
> be updated. All three should be retargetted at 5.9.
Good to know! I'll resubmit them,
Hi there!
I've got a few merge proposals which were recently closed by the Qt
cleanup bot due to lack of activity; I've reopened them and ping a few
people, but to no avail.
All but one are tiny, and I would appreciate if someone could spend a
couple of minutes to give the final +2 or to advise
On 06/23/2017 10:08 AM, Simon Hausmann wrote:
I think send() should be fixed to support more than just strings as
parameters. For example in browsers
you can use send() with array buffers and blob objects. We don't support
the latter, but the former we do
and they are also our mapping for
Hi all,
my understanding looking at the implementation of the
XMLHttpRequest.send() method in QtDeclarative [1] is that the
said method only accepts UTF-8 data as parameter.
Now, I would like to be able to send arbitrary data (in order to, for
example, upload a JPEG image to flickr) and I
On 25/04/2017 09:29, Martin Smith wrote:
>> What would be incorrect as those APIs are only internal for C++, but
>> public for QML or v.v.
>
> Then we need \cpponly and \qmlonly, or something like that.
This is calling for future headaches, when you start adding python or
other languages.
It's
Hi all,
in addition to making QMimeType usable from QML [1], jpnurmi also
suggested of exposing QMimeDatabase as a singleton.
The open question is where this element should be added: I suggested
QtQtml.Models, given that it's a database, but maybe creating a separate
module QtQml.Utils might be
On 16/04/2017 21:13, Olivier Goffart wrote:
>
> Q_GADGET's overhead is basically the cost of the QMetaObject. So it's there,
> but it's quite small.
> If there is an use for a class to be a Q_GADGET, I think it should be added.
For the record:
https://codereview.qt-project.org/#/c/191777/
Hi all,
I'm about to use QMimeType in my application, and I'd found it useful
if it were a Q_GADGET. Can I just go on and submit a patch to add that,
or are there some cons (a small increase on the library size, I assume)?
In general: is it a good idea to add Q_GADGET to non QObject classes
On 11/25/2016 03:40 PM, Oswald Buddenhagen wrote:
i'm expecting a flurry of retargeting requests of changes from 5.6 and
5.7 to 5.8 now.
I have a few changes targeting 5.6 which are waiting for review:
On 10/11/2016 11:55, Frederik Gladhorn wrote:
> The last gap are Linux styles. The situation with KDE is actually quite
> interesting, since the platform is QStyle based. We do not believe in QStyle
> based styles for QQC2 as it stands. They will never have the same performance
> level of the
Hi there!
I'm working on a project of a desktop application using the
QtQuickControls module. I occasionally run into small issue, but I'm
generally satisfied with the state of the controls (I'm working on
Linux, I hope that other platforms are working equally well).
What makes me worry a bit
On 07/26/2016 05:12 PM, Andrea Bernabei wrote:
> I'd like to propose changing the default value of QML Flickable's
> flickableDirection in Qt 5.8.
I vote against it :-)
While I agree that your proposal makes sense, I would advise against
implementing it before Qt 6. There are lots of programs
On 01/06/2016 18:12, Mathias Hasselmann wrote:
> Yes, when it comes to initializer lists the trailing comma looks ugly to
> me. Because of the inconsistent two-space indent for the first
> initializer. Because line starts of are not aligned.
In my projects I use this style:
MyObject::MyObject():
Hi all!
I wanted to try fixing this bug:
https://bugreports.qt.io/browse/QTBUG-49876
(in QML, the dragged item disappears during the drag and drop operation,
if the dragType is Drag.Automatic -- external drag)
First of all, after some investigation I wonder whether this is actually
a bug, or
On 25/02/2016 13:20, Welbourne Edward wrote:
> André Somers used m* for minutes and metres, footnoting:
>> )* Note the first clash already...
>
> I think it is fairly sane to just insist that SI units take precedence,
> especially given that we support multi-letter unit names (e.g. pt, px,
> mm,
On 23/02/2016 01:31, deDietrich Gabriel wrote:
> The story behind having QModelIndex and QItemSelectionModel exposed
> to the QML engine was to solve the selection problem in the Qt Quick
> Controls 1 TreeView. TableView could use a simple selection model
> because of the trivial mapping between
Hi all!
Since Qt 5.5, the QItemSelectionModel class is exposed to QML as
ItemSelectionModel (in the QtQml.Models module):
http://doc.qt.io/qt-5/qml-qtqml-models-itemselectionmodel.html
Apart from having almost no documentation, this component seems to be
rather hard to use in QML: its methods
On 18.06.2015 15:59, Smith Martin wrote:
Why not leave current Qt modules as they are, without namespaces and with the
Q prefix on classes, and just introduce the option of adding a new module to
Qt by putting it in a namespace named QtFoo without the Q prefix on class
names, or adding it
Hi Massimo,
On 04/28/2015 07:46 AM, Massimo Callegari wrote:
I just wanted to share my specific(?) case so if someone stumbles on it, they
can find the solution out of the box :)
I also stumbled on this problem once. Luckily, the documentation is
quite clear on this -- the problem is that
On 04/23/2015 04:53 AM, Konstantin Ritt wrote:
We already have a complete solution -
https://codereview.qt-project.org/110685
That looks good.
All we need now is to fix the behavioral regression introduced in 5.4.
But if I understand the code correctly, the fix above gives developers
an
On 04/23/2015 01:36 PM, Gunnar Sletta wrote:
I think we should strive to not introduce regressions on purpose. Hence:
- Revert the behavioral change in 5.4 which adds rotation to JPEGs
- Have opt-in rotation in QImageReader.
- Keep TIFF rotation as it is (and change it to the Qt-wide
On 04/23/2015 02:34 PM, André Somers wrote:
What is the problem with using
Image {
source: someImage.jpg
autorotate: true
}
Again: note that QImage != QML Image
I don't like globals if they can be avoided. In this case, I think they can.
I could certainly live with that, but
On 04/22/2015 09:54 PM, André Pönitz wrote:
However, we do have context here, namely existing behaviour in Qt 5.x,
as well as certain general promises given for changes between Qt 5.x and
Qt 5.(x+1).
I see it as a long standing bug which finally got fixed.
But the problem is that the
On 04/22/2015 09:39 AM, André Somers wrote:
I'm with Konstatin on this one: it seems like a regression to me. It
would be a useful feature to add, but then add it in such a way that it
is actually clear what it does, the user can control it, and it does not
break applications. I think it _is_
On 04/17/2015 11:48 AM, Allan Sandfeld Jensen wrote:
If we go with the QImageReader level, it could be an QImageIOHandler::Option,
and possibly be set different between JPEG and TIFF by default. The real
problem is what we decide the default for JPEG should be now.
IMHO, QImageReader default
Hi Frederik,
On 04/09/2015 04:04 PM, Frederik Gladhorn wrote:
We want to give you the code, here it is :)
https://codereview.qt-project.org/#/admin/projects/qt-labs/qtquickcontrols2
[...]
Feedback welcome!
If I understand correctly, these controls are intended to be a
cross-platform set of
On 04/24/2014 03:11 PM, Joshua Kolden wrote:
[...]
We have a solution that works very well for us using QVariantMaps and an
MVC pattern / strong separation between data objects and view. It
appears to me that most people are having this issue because it’s not
common to use MVC with QtWidgets.
On 03/30/2014 03:56 PM, Gladhorn Frederik wrote:
A fix for this would certainly be appreciated.
http://qt-project.org/wiki/Gerrit-Introduction
On Saturday 29. March 2014 14.56.16 Rex Dieter wrote:
Ruslan Nigmatullin wrote:
If the changes will be done and accepted is there any hope to have
On 01/15/2014 10:48 PM, Alan Alpert wrote:
This approach could also apply to the original suggestion by Alberto,
in the absence of a separate add on module (which Sean couldn't use
because of the QtQuick.Controls dependency). Just requires a higher
bar for code review/quality, but I'm
Hi all!
For one of my projects, I found the need to merge several models into
a single model. I wrote a class for it, and I think it's generic enough
to be useful for other people, and I wonder if it could be put into Qt
itself:
On 12/09/2013 10:00 AM, Alan Alpert wrote:
Question does seem a bit clearer. But I think the answer is the same -
ListView shouldn't be using context properties anymore. Well, it's
worthwhile for the convenience here but maybe add an attached property
reference as well for those cases needing
Hi all!
One of the issues that has most bothered me when developing in QML is
dealing with the same variable name in item properties and context
properties. For example:
// model is a context property
Loader {
property variant model: model
sourceComponent: someComponent
}
The code
On 12/09/2013 12:54 AM, Alan Alpert wrote:
On Sun, Dec 8, 2013 at 5:38 AM, Alberto Mardegan
ma...@users.sourceforge.net wrote:
[...]
What do you mean current context? The problem you seem to be hitting
is that there is another symbol in the current context that you want
to avoid, so
On 03/15/2013 02:51 PM, Oswald Buddenhagen wrote:
On Fri, Mar 15, 2013 at 12:49:55PM +0100, Axel Waggershauser wrote:
On Fri, Mar 15, 2013 at 8:11 AM, Thiago Macieira thiago.macie...@intel.com
wrote:
4) What about consistent placement of the ',' in class member
initialization lists? I've
On 03/02/2013 01:06 PM, Olivier Goffart wrote:
If i understand the test properly, it waits two seconds for a window to
receive some events. But it may very well happen that the seconds are not
enough, because the tests are run on some busy virtual machine or because the
window manager is
Hi all!
The CI bot reported a failure in tst_qwidget when merging
https://codereview.qt-project.org/#change,42990,patchset=8
(see the last comment from Qt Continuous Integration System).
I can reproduce the same failure under ubuntu 13.04 running XFCE.
Then I removed my patch (by checking out
On 02/13/2013 12:49 PM, Knoll Lars wrote:
* Friday 22. February: If you have a larger feature/feature branch (not
yet merged) that you want to have in the release you must have told the
release team (by mail to releases@) by then.
I'd like to have the X11 Embedding in 5.1:
On 02/03/2013 04:45 AM, Martin Jones wrote:
Alan is for all intents and purposes acting as maintainer now, so I think
we should make it official.
+1!
Ciao,
Alberto
___
Development mailing list
Development@qt-project.org
On 01/14/2013 09:29 AM, André Somers wrote:
I am not fan of this change. I think the API of QAIM is already very
complex. Adding more methods that basically only sort-of mirror existing
methods but for a more confined use-cases only makes that situation
worse. For instance, you now get a
On 01/14/2013 11:37 AM, André Somers wrote:
[...]
top of them. Note that you can also use a proxy to map a table model to
a list by mapping the data in columns to different roles. The base class
would not be a QListModel, but the data would be available from the
first column anyway. When using
On 01/12/2013 11:59 PM, Nils Jeisecke wrote:
Hi,
what about adding a new Quick item for enhanced QAbstractItemModel access.
ListModelAdapter {
id: myModelAdapter
sourceModel: myModel
}
ListView {
model: myModelAdapter.sourceModel
delegate: Text {
MouseArea {
On 01/10/2013 05:46 PM, Alberto Mardegan wrote:
I'd like to make C++ models more usable from QML; in the net there
are several blog posts illustrating how to achieve that, but IMHO it
would be better if at least some of these handy features were in
QAbstractListModel itself:
- count
On 01/11/2013 04:47 PM, Simon Hausmann wrote:
So I got in touch with them and they're willing to contribute the code to the
Qt
project. I'm therefore seeking approval from the Qt project to importing
Snowshoe
into Gerrit, with
[...]
I like the idea, but I'm a bit concerned about the future
Hi all!
I'd like to make C++ models more usable from QML; in the net there
are several blog posts illustrating how to achieve that, but IMHO it
would be better if at least some of these handy features were in
QAbstractListModel itself:
- count property
- get(index) invocable method,
1 - 100 of 136 matches
Mail list logo
