On Saturday, 26 May 2018 18:20:17 -03 Richard Weickelt wrote:
> > There are JavaScript interpreters for microcontrollers (see Duktape and
> > Jerryscript). But those are designed to run on tens of *kilobytes* of RAM.
> > You can't compare them to Qt, as they have special limitations to run
> > that
> There are JavaScript interpreters for microcontrollers (see Duktape and
> Jerryscript). But those are designed to run on tens of *kilobytes* of RAM.
> You
> can't compare them to Qt, as they have special limitations to run that way.
> For example, neither implementation supports "eval".
I wo
On Saturday, 26 May 2018 14:01:59 -03 Jean-Michaël Celerier wrote:
> Well, you mention Nest thermostats : those actually run a Linux with 512 mb
> of RAM - more than enough for some QtCore goodness.
I said "similar to". Yes, there are some overkill devices for the needs they
have. Usually because
Well, you mention Nest thermostats : those actually run a Linux with 512 mb
of RAM - more than enough for some QtCore goodness.
> Which is why I don't think Qt has a role to play in these types of
devices.
This I don't understand. There would be so much to win in terms of code
reuse - currently I
On Saturday, 26 May 2018 09:12:25 -03 Jean-Michaël Celerier wrote:
> If only there was a way to be able to use Qt without all the PIMPLing and
> just have QObjectPrivate be a "normal" QObject member !
You'd save maybe 10% of the allocations. Don't forget that the privates have a
lot of internals
On Saturday, 26 May 2018 03:38:27 -03 Jean-Michaël Celerier wrote:
> It's not about subclassing QQuickControl, it's about running code without a
> JIT / interpreter. Even if the cost in startup time and performance is
> minimal, it is not as fast as raw C++ code - and there's nothing wrong with
> w
On 26 May 2018 at 12:20, Uwe Rathmann wrote:
> Hi Robin,
>
>> Why does it need to be? I have never needed to subclass QQuickControl,
>> personally, so I have never brought this topic up.
>
> For the same reason all other controls from QC2 do subclass it. If you
> want to participate in mechanisms
On Sat, 26 May 2018 12:05:38 +, Simon Hausmann wrote:
> P.S.: Are you sure the stops: [ ... ] assignment works?
You are right: I forgot to mention this extra piece of code:
QMetaType::registerConverter< QJSValue, QskGradientStop >(
[] (const QJSValue& value) -> QskGradientStop
> Jędrzej had a beautiful proof of concept at some point for QObject to
combine the object and d-pointer allocation into one.
If only there was a way to be able to use Qt without all the PIMPLing and
just have QObjectPrivate be a "normal" QObject member !
---
Jean-Michaël Celerier
http://ww
Hi,
Jędrzej had a beautiful proof of concept at some point for QObject to combine
the object and d-pointer allocation into one.
That's where I had the idea that perhaps this idea could be extended all the
way to QML, so that the instantiation of a .qml file would collect all object
and d-poi
Gyus, why you would not hire Uwe to improve QML/Qt/QQC1/QQC2?! :) -- Best regards,AlekseyLinked in https://www.linkedin.com/in/alekseykontsevich 26.05.2018, 12:32, "Uwe Rathmann" :On Fri, 25 May 2018 22:35:58 +0200, Robin Burchell wrote: The first point I would make in reply, though, is that th
On Fri, 25 May 2018 22:35:58 +0200, Robin Burchell wrote:
> The first point I would make in reply, though, is
> that the convenience of creating code with a/b/c are going to be
> significantly better in my experience.
Code for d) look like this:
https://github.com/uwerat/qskinny/blob/master/examp
Hi Robin,
> Why does it need to be? I have never needed to subclass QQuickControl,
> personally, so I have never brought this topic up.
For the same reason all other controls from QC2 do subclass it. If you
want to participate in mechanisms ( like font/locale/palette propagation
) that are impl
13 matches
Mail list logo
