-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 well,
you have pretty well summarized your arguments so I will just stop
wasting o
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 modules must be in qt5 latest a week before FF. T
Il 21/11/19 09:17, Ulf Hermann ha scritto:
Typed Model Data
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 an
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 Repeater.delegate).
>> Will something similar still be possible?
>
>
I'd like to inform everyone that the SAX classes for reading and writing XML
files are about to be deprecated in Qt 5.15, and
QXmlStreamReader/QXmlStreamWriter should be used instead.
As a consequence QDomDocument has been re-implemented using QXmlStreamReader,
and Qt 6 will switch to the new i
On Tuesday, 26 November 2019 06:50:28 PST Arnaud Clère wrote:
> value.meta(qmColumns,"key,value").bind(map.iterator())
I really, REALLY do not like this line.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
Now, this is the discussion I was hoping for at QtCS :-)
> -Original Message-
> From: Thiago Macieira
>
> > - it is frequent to have to save/load our types and then send/receive
> > them to some server/device using, say QSettings/QJsonDocument for the
> > first and JSON/CBOR for the latte
Hi,
On 21 Nov 2019, at 13:52, Oswald Buddenhagen
mailto:oswald.buddenha...@gmx.de>> wrote:
On Thu, Nov 21, 2019 at 08:50:10AM +, Volker Hilsheimer wrote:
== Discussed and Agreed Proposal ==
We start with Qt 5.15/14/12 (ie 5.15 is “dev” in the Qt 5 series), and continue
to merge 5.15 into d
On 11/26/19 12:35 PM, Olivier Goffart wrote:
"QML Strict is as subset of QML which is more maintainable and
performs better"
Isn't it that way:
QML is for convenience but expensive. C++ is often less convenient but
with better performance and lower memory footprint. QML Strict is a
compromise
On 26.11.2019 14:16, Konstantin Tokarev wrote:
>
>
> 26.11.2019, 16:11, "Mårten Nordheim" :
>> On 26.11.2019 13:54, Konstantin Tokarev wrote:
>>> What about an elephant in the room, i.e. HTTP/3? Will it be implemented
>>> anytime soon?
>>
>> Given the size and requirements of QUIC (and http3)
26.11.2019, 16:11, "Mårten Nordheim" :
> On 26.11.2019 13:54, Konstantin Tokarev wrote:
>> What about an elephant in the room, i.e. HTTP/3? Will it be implemented
>> anytime soon?
>
> Given the size and requirements of QUIC (and http3) we plan to wait for
> it to stabilize and get closer to rel
On 26.11.2019 13:54, Konstantin Tokarev wrote:
> What about an elephant in the room, i.e. HTTP/3? Will it be implemented
> anytime soon?
>
Given the size and requirements of QUIC (and http3) we plan to wait for
it to stabilize and get closer to release, then we can consider
3rd-party libraries
What about an elephant in the room, i.e. HTTP/3? Will it be implemented anytime
soon?
21.11.2019, 10:55, "Maurice Kalinowski" :
> Hi,
>
> Following the notes taken on the Networking session:
>
> - What to do in Networking for Qt 6
> ○ https://bugreports.qt.io/browse/QTBUG-
Hi all,
We released Qt Design Studio 1.3.1 today, see
https://www.qt.io/blog/qt-design-studio-1.3.1-released
Big thanks to everyone involved!
Best Regards,
Thomas Hartmann
___
Development mailing list
Development@qt-project.org
https://lists.qt-proje
+1
BR,
Denis
вт, 26 нояб. 2019 г. в 13:35, Sze Howe Koh :
> On Tue, 26 Nov 2019 at 17:07, Samuel Gaist wrote:
> >
> >
> >
> > > On 26 Nov 2019, at 09:36, Alex Blasche
> wrote:
> > >
> > > Hi,
> > >
> > > The QCanbus API is part of the QtSerialBus module. Since its first
> release it has come a
Hi all,
Branching from '5.14' '5.14.0' is done (actually already at the end of last
week). Staging in '5.14.0' is now restricted to release team only.
So from now on only fixes for Qt 5.14.0 blockers in '5.14.0'; we are trying to
get RC out during this week and so on we need to minimize new chan
> Lookup by ID? You mean set the object name like you did in your example
> in your talk at QtWS? I protested then, and I will protest now again.
> Don't. Really: don't. If you are talking about re-usability and
> maintainability of your code elsewhere, then advocating this practice is
> really
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 even
from deep leaf files. Removing that capability is quite a drastic measure.
On 26.11.19 11:48, André Somers 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 Repeater.delegate).
>>
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 Repeater.delegate).
Will something similar still be possible?
You should r
On 25.11.19 16:55, Robin Burchell wrote:
> On Mon, Nov 25, 2019, at 3:53 PM, Ulf Hermann wrote:
>> Yes, but the problems with this construct are the same as with generic
>> context properties: Your QML component requires some context that it
>> doesn't declare. Therefore your code is not reusable
On 25.11.19 12:15, Robin Burchell wrote:
>> We could detect this in qmllint by just continuing the search for IDs
>> even if we've found a property.
> We could, but if I may gently suggest, I think I can count most of the people
> who use qmllint on a regular, useful basis on one hand ;-).
You'r
On 26/11/2019 09:34, Chris Adams wrote:
On Mon, Nov 25, 2019 at 9:34 PM 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
v
On Tue, 26 Nov 2019 at 17:07, Samuel Gaist wrote:
>
>
>
> > On 26 Nov 2019, at 09:36, Alex Blasche wrote:
> >
> > Hi,
> >
> > The QCanbus API is part of the QtSerialBus module. Since its first release
> > it has come a long way. In particular, André Hartmann & Denis Shienkov made
> > big contri
+1
--Karsten
-Original Message-
From: Development On Behalf Of Andy Shaw
Sent: Dienstag, 26. November 2019 10:35 Uhr
To: Alex Blasche ; development@qt-project.org
Subject: Re: [Development] Nominating André Hartmann for maintainer for QCanBus
API
+1
Andy
-Opprinnelig melding
+1
Andy
-Opprinnelig melding-
Fra: Development på vegne av Alex Blasche
Dato: tirsdag 26. november 2019 09:39
Til: "development@qt-project.org"
Emne: [Development] Nominating André Hartmann for maintainer for QCanBus API
Hi,
The QCanbus API is part of the QtSerialBus mo
> On 26 Nov 2019, at 09:36, Alex Blasche wrote:
>
> Hi,
>
> The QCanbus API is part of the QtSerialBus module. Since its first release it
> has come a long way. In particular, André Hartmann & Denis Shienkov made big
> contributions over time. For that I am very grateful. Thank you.
>
> As
thanks Elvis, Filippo, Ulf,
now I know what to do the next months to make my apps QML3 - ready ;-)
yes - then my code will be better re-usable and cleaner as now
will blog about all those refactorings
ciao
ekke
Am 26.11.19 um 09:20 schrieb Elvis Stansvik:
> Den mån 25 nov. 2019 kl 22:08 skrev
Hi,
The QCanbus API is part of the QtSerialBus module. Since its first release it
has come a long way. In particular, André Hartmann & Denis Shienkov made big
contributions over time. For that I am very grateful. Thank you.
As the current maintainer of the QCanBus API I would like to hand the
On Mon, Nov 25, 2019 at 9:34 PM 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 to not allow that
Den mån 25 nov. 2019 kl 22:08 skrev Filippo Cucchetto
:
>
> @Ekke
> I think you should redesign your qml the other way around. For your problem
> there're multiple solutions
> 1) Use some sort of StackView.view attached property. This is *usually*
> implemented with a simple upward hierarchy look
31 matches
Mail list logo
