On 27-11-19 07:03, Jani Heikkinen wrote:
Hi!
Qt 5.14.0 is in its final steps and it is time to start thinking Qt 5.15
release schedule. I don't see any reason/evidence how we could cut the time so
my proposal is based on previous releases:
Qt 5.15 initial schedule proposal:
- All new
Hi,
The Qt5 PMF connect syntax is wonderful and very elegant compared to Qt
4.
Unless, ofc, you have overloaded signals, which makes it painful to
write and read. Not even qOverload makes it look much better.
I suggest we rename such signals, as KDE is already doing for KF6 (maybe
leave
On 15.10.2019 12.35, Oswald Buddenhagen wrote:
> the gist is that this somewhat complicated downmerge process exists for
> good reasons. it shifts the "logistical" load of dealing with the
> branching from every contributor to the few people involved in the
> branch management.
>
> history
On Tuesday, 26 November 2019 23:13:46 PST Arnaud Clère wrote:
> -Original Message-
> From: Thiago Macieira
>
> > > value.meta(qmColumns,"key,value").bind(map.iterator())
> >
> > I really, REALLY do not like this line.
>
> I was going to explain all meta(...) were never required, but
> On 25 Nov 2019, at 22:18, Filippo Cucchetto
> wrote:
>
> Having followed the evolution and first announcement of Qml/Quick QML3 seems
> like an admission of guilt.
> I remember when a lot of people complained about the use of Javascript as a
> scripting language and further
> more on the
Hi,
> I didn't know that there is going to be one more subclass. Will
QQuickAction be a public class?
In Qt 5, AFAIK it exists with duplicated code in QuickControls1,2 as a
class exposed to QML (no public C++ class). The duplication (and also
need for the functionality for WebAction) is one
On 26 Nov 2019, at 12:35, Olivier Goffart
mailto:oliv...@woboq.com>> wrote:
On 25.11.19 16:36, André Somers wrote:
On 25-11-19 15:53, Ulf Hermann wrote:
Yeah, that's going to make using QML in actual applications a whole lot
harder. For instance, sometimes access to some root node is needed
> as discussed on the change, there is not much one can do with the newly
> introduced QGuiAction; it serves as a base class for QAction and
> QQuickAction, The naming follows the Q(Gui)Application pattern.
I didn't know that there is going to be one more subclass. Will QQuickAction be
a public
On 27.11.19 11:19, Friedemann Kleint wrote:
Hi,
as discussed on the change, there is not much one can do with the newly
introduced QGuiAction; it serves as a base class for QAction and
QQuickAction, The naming follows the Q(Gui)Application pattern.
> QMenu *menu() const;
> -> static QMenu
Volker Hilsheimer (26 November 2019 15:42) wrote:
[snip]
> If I understood and remember the discussion, then the proposed flow
> would be:
>
> * we make changes to e.g changes-5.12.7 in the 5.12 branch
> * once 5.12.7 is released, release team copies the file into dev, and
> makes a separate
On 27/11/2019 11:39, Milian Wolff wrote:
Personally, I hope the answer is that this will remain supported. The only
disadvantage is the runtime type introspection, which should/could be solved
via Ulf's idea of something like an inline interface/trait component. Such
that eventually we can do
On Tue, Nov 26, 2019, at 8:56 AM, Ulf Hermann wrote:
> We're also changing the way views and delegate work. If you want to use
> the "index" in a Repeater's delegate you'll have to declare that in QML
> 3, using a required property:
>
> Repeater {
> model: 10
>
> Text {
>
On Mittwoch, 27. November 2019 10:35:23 CET Giuseppe D'Angelo via Development
wrote:
> Il 27/11/19 09:52, Ulf Hermann ha scritto:
> > That depends on how we do the model/delegate matching mentioned above.
> > As stated above, I don't have a solution, yet. If you have an idea, let
> > us know. I
+1 from my side
Mahmoud added new features to an already existing code base in a fast and
quality way which amazed me.
Mandatory disclaimer: I am also in the Qt Design Studio team.
From: Development On Behalf Of Thomas
Hartmann
Sent: Mittwoch, 27. November 2019 10:02
To:
Hi,
as discussed on the change, there is not much one can do with the newly
introduced QGuiAction; it serves as a base class for QAction and
QQuickAction, The naming follows the Q(Gui)Application pattern.
> QMenu *menu() const;
> -> static QMenu *QMenu::menuForAction(QAction *action);
>
On Dienstag, 26. November 2019 20:32:20 CET Arno Rehn wrote:
> On 26/11/2019 08:56, Ulf Hermann wrote:
> >> We have some code that evaluates JS in custom QQmlContexts with certain
> >> "magic" context properties set (sort of like the "index" or "modelData"
> >> context properties in delegates like
On Tue, Nov 26, 2019 at 02:42:46PM +, Volker Hilsheimer wrote:
but I’d need a practical proposal to replace it with. Do I understand
correctly that you’d rather go “all in”, i.e once we are ready, flip
all branches to “cherry-pick only”?
all-in is one option, yes.
it has the advantage
Hi.
+1 from me.
Disclaimer: Also in the same team.
-Miikka
From: Development On Behalf Of Thomas
Hartmann
Sent: keskiviikko 27. marraskuuta 2019 11.02
To: development@qt-project.org
Subject: [Development] Nominating Mahmoud Badri as approver
Hi all,
I'd like to nominate Mahmoud Badri as an
Il 27/11/19 09:52, Ulf Hermann ha scritto:
That depends on how we do the model/delegate matching mentioned above.
As stated above, I don't have a solution, yet. If you have an idea, let
us know. I can imagine generating some C++ from such code that does the
model/delegate matching at run-time
+1
From: Development on behalf of Alessandro
Portale
Sent: Friday, November 8, 2019 21:35
To: Qt Development
Subject: [Development] Nominating Cristian Adam as approver
Hi,
I like to propose Cristian Adam as an approver.
Cristian has been around Qt
Hi all,
I'd like to nominate Mahmoud Badri as an approver for the Qt Project.
Mahmoud has been working on Qt 3D Studio and now is contributing to Qt Design
Studio and Qt Creator.
He is leading the designer experience team for the Qt Company in Oulu.
Qt Commits:
Dear Qt friends, hackers and freaks,
recently I've noticed a refactoring changes regarding QAction and QActionGroup,
happening inside "dev" branch of Qt
(https://codereview.qt-project.org/c/qt/qtbase/+/265909). I didn't have a chance
to review it before it got merged, I just missed it. So I took
>> We brainstormed a bit about how a model could declare its items' data
>> type in QML, so that we could statically check model against delegate
>> types. We will need this when compiling QML 3 to C++. We didn't come up
>> with anything really great, though. This needs more work.
>
> Just
> Anyway, how would I idiomatically register a bunch of dynamically
> created C++ objects with QML then? As an example, we're automatically
> detecting hardware stuff and creating interface objects based on that.
> These interface objects are then passed to QML which we use to implement
> state
On 22/11/2019 18:17, Giuseppe D'Angelo via Development wrote:
Il 21/11/19 13:13, Robert Loehning ha scritto:
** [https://doc.qt.io/qt-5/qregularexpression.html QRegularExpression]
This should mostly be fuzzing libpcre itself...
Note that users should NEVER use / accept untrusted regular
25 matches
Mail list logo
