On 27.04.2014 22:41, Thiago Macieira wrote:
Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu:
Then adding 100MB just to run QML really hurts, and you start
looking for alternatives, like using only QWidgets with very
limited OpenGL support or not to use a Qt-GUI at all.
Of those 100
On 28 Apr 2014, at 07:53, Peter Kümmel syntheti...@gmx.net wrote:
On 27.04.2014 22:40, Thiago Macieira wrote:
Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
On 26.04.2014 17:39, André Pönitz wrote:
You could have made the point declarative structures are good for GUI
description
On 28.04.2014 08:10, Kurt Pattyn wrote:
On 28 Apr 2014, at 07:53, Peter Kümmel syntheti...@gmx.net wrote:
On 27.04.2014 22:40, Thiago Macieira wrote:
Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
On 26.04.2014 17:39, André Pönitz wrote:
You could have made the point declarative
Em seg 28 abr 2014, às 07:35:10, Robert Iakobashvili escreveu:
Sorry, but the above is not helpful.
I'd never jump to conclusions and statements without
in-hands knowledge of the subject to talk about.
You asked for my personal opinion the moment that you emailed me directly
without the
Em seg 28 abr 2014, às 08:33:23, Peter Kümmel escreveu:
ATM the problem is to get started because I don't know much about the
current architecture of the graphic stack.
Any hints where to start for a first hello world?
Maybe a translation from QML to a .ui file could be a first step?
Em seg 28 abr 2014, às 08:00:56, Peter Kümmel escreveu:
On 27.04.2014 22:41, Thiago Macieira wrote:
Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu:
Then adding 100MB just to run QML really hurts, and you start
looking for alternatives, like using only QWidgets with very
limited
On 28 Apr 2014, at 07:53, Peter Kümmel syntheti...@gmx.net wrote:
...
ATM the problem is to get started because I don't know much about the
current architecture of the graphic stack.
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
-bounces+thomas.hartmann=digia@qt-project.org
[development-bounces+thomas.hartmann=digia@qt-project.org] on behalf of
Thiago Macieira [thiago.macie...@intel.com]
Sent: 28 April 2014 02:34
To: development@qt-project.org
Subject: Re: [Development] Question about Qt's future
Em seg 28 abr 2014
Hi,
Another idea is to allow C++ companion objects, that would
take the place of any Java Script code for people who
prefer C++. A companion object would be a QObject
paired with the QML object, that has access to the
QML context. The QObject would then define a couple
of signals/slots that
?
Kind Regards,
Thomas Hartmann
From: Nils Jeisecke [njeise...@saltation.de]
Sent: 28 April 2014 11:00
To: Hartmann Thomas
Cc: development@qt-project.org
Subject: Re: [Development] Question about Qt's future
Hi,
Another idea is to allow C++ companion objects
Also what is the problem with:
MouseArea {
onClicked: companion.mouseAreaClicked();
}
Where is the event handler's argument (the one that's kind of
invisible in QML and requires you to read the documentation, I think
it's called mouse :-).
Could this be a function binding instead?
Hartmann Thomas schreef op 28-4-2014 11:32:
Hi,
yes, writting C++ inline in QML would be another tooling nightmare. Also
what is the problem with:
MouseArea {
onClicked: companion.mouseAreaClicked();
}
If tooling creates the companion object for you (In a wizard) and code
On 28.04.2014 09:32, Gunnar Sletta wrote:
ATM the problem is to get started because I don't know much about the
current architecture of the graphic stack.
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
-project.org
Subject: Re: [Development] Question about Qt's future
Also what is the problem with:
MouseArea {
onClicked: companion.mouseAreaClicked();
}
Where is the event handler's argument (the one that's kind of
invisible in QML and requires you to read the documentation, I think
it's called
: development-bounces+thomas.hartmann=digia@qt-project.org
[development-bounces+thomas.hartmann=digia@qt-project.org] on behalf of
André Somers [an...@familiesomers.nl]
Sent: 28 April 2014 11:57
To: development@qt-project.org
Subject: Re: [Development] Question about Qt's future
Hartmann
On 28 Apr 2014, at 9:32 AM, Gunnar Sletta wrote:
On 28 Apr 2014, at 07:53, Peter Kümmel syntheti...@gmx.net wrote:
...
ATM the problem is to get started because I don't know much about the
current architecture of the graphic stack.
On Mon, Apr 28, 2014 at 4:39 AM, Hartmann Thomas
thomas.hartm...@digia.comwrote:
Hi,
gluing together C++ and Java Script is currently not always that easy.
The solution I propose is the option to write C++ code in the exact same
way you currently write Java Script code.
This means every QML
2014-04-27 13:31 GMT+02:00 Peter Kümmel syntheti...@gmx.net:
On 21.04.2014 13:39, Roland Winklmeier wrote:
- Memory consumption: Even a mini example took about 70 MB of memory,
QtWidgets need a lot less. This is not a complain, I know the JS runtime
needs its initial memory. It was just
On 28-Apr-14 16:36, Sze Howe Koh wrote:
To check if I've understood you correctly: You've found that
classifying QML as declarative distorts developers' expectations of
the tools?
The term declarative is mainly used here as a synonym for perfectly
toolable. So yes, I would expect that every
On 25.04.2014 12:18, Joerg Bornemann wrote:
Yep, I hear people keep repeating the mantra QML is declarative. It's
just QML/JS that isn't.
I think the declarative-mantra is a good idea, especially when used for
_specifying_ (not programming) the GUI.
At Adobe they tried it with pure
On 28.04.2014 18:01, Tony Van Eerd wrote:
On 25.04.2014 12:18, Joerg Bornemann wrote:
Yep, I hear people keep repeating the mantra QML is declarative. It's
just QML/JS that isn't.
I think the declarative-mantra is a good idea, especially when used for
_specifying_ (not programming) the
On 24.04.2014 21:15, Attila Csipa wrote:
solutions to cross platform mobile development :( After playing a bit
with Xamarin (yes, I know, but put aside the C# hate for a minute), it's
quite striking what different approaches can result in (and it also made
it quite clear what Qt is doing
On 25.04.2014 12:18, Joerg Bornemann wrote:
Yep, I hear people keep repeating the mantra QML is declarative. It's
just QML/JS that isn't.
I think the declarative-mantra is a good idea, especially when used for
_specifying_ (not programming) the GUI.
At Adobe they tried it with pure C++
On 26.04.2014 17:39, André Pönitz wrote:
You could have made the point declarative structures are good for GUI
description for Qt Widget's .ui files, after all, .ui files contents
pretty much _is_ declaring layout nesting and property values.
Just an idea:
Declarative-only QML files could be
On 21.04.2014 13:39, Roland Winklmeier wrote:
- Memory consumption: Even a mini example took about 70 MB of memory,
QtWidgets need a lot less. This is not a complain, I know the JS runtime
needs its initial memory. It was just one factor, because our
application is running as an addon to
On 27/04/2014 12:55, Peter Kümmel wrote:
Having imperative code on the JS side is also the root of the rejection of QML
for many C++ developers. If QML would have been just a improved .ui nobody
would
have complained.
+1
--
(o | Yves Bailly | -o)
//\ | Linux Dijon
On Sunday 27 April 2014 12:55:58 Peter Kümmel wrote:
Having imperative code on the JS side is also the root of the rejection of
QML for many C++ developers. If QML would have been just a improved .ui
nobody would have complained.
+1
Frank
___
creating any js bindings.
Simon
Opprinnelig melding
Fra: Yves Bailly
Sendt: 16:52 søndag 27. april 2014
Til: development@qt-project.org
Emne: Re: [Development] Question about Qt's future
On 27/04/2014 12:55, Peter Kümmel wrote:
Having imperative code on the JS side is also the root
Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu:
Then adding 100MB just to run QML really hurts, and you start
looking for alternatives, like using only QWidgets with very
limited OpenGL support or not to use a Qt-GUI at all.
Of those 100 MB, 30 MB are taken by QtCore and QtGui
Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
On 26.04.2014 17:39, André Pönitz wrote:
You could have made the point declarative structures are good for GUI
description for Qt Widget's .ui files, after all, .ui files contents
pretty much _is_ declaring layout nesting and property
Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
Having imperative code on the JS side is also the root of the rejection of
QML for many C++ developers. If QML would have been just a improved .ui
nobody would have complained.
We'd end up with one of the problems of CSS which is that you
On Sun, Apr 27, 2014 at 10:37 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
Having imperative code on the JS side is also the root of the rejection of
QML for many C++ developers. If QML would have been just a improved .ui
nobody
On 27 April 2014 22:31, Mark Gaiser mark...@gmail.com wrote:
Actually, you can..
http://css-tricks.com/a-couple-of-use-cases-for-calc/
And even Internet Explorer has support for it:
http://caniuse.com/#feat=calc
It's a variant of the expression() facility that IE has offered to CSS
since
On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
Having imperative code on the JS side is also the root of the rejection of
QML for many C++ developers. If QML would have been just a improved .ui
nobody would have
Em seg 28 abr 2014, às 00:55:12, André Pönitz escreveu:
On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
Having imperative code on the JS side is also the root of the rejection
of
QML for many C++ developers. If
On Mon, Apr 28, 2014 at 6:53 AM, Thiago Macieira
thiago.macie...@intel.comwrote:
Em dom 27 abr 2014 15:01:10 você escreveu:
It's not the only available choice. Widgets are available. They just
look
horrible because no one has done any work to make them look native.
Is my understating
On 27.04.2014 22:40, Thiago Macieira wrote:
Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
On 26.04.2014 17:39, André Pönitz wrote:
You could have made the point declarative structures are good for GUI
description for Qt Widget's .ui files, after all, .ui files contents
pretty much
On Fri, Apr 25, 2014 at 10:21:04AM +0800, Sze Howe Koh wrote:
On 24 April 2014 00:35, André Pönitz apoen...@t-online.de wrote:
On Wed, Apr 23, 2014 at 10:50:23PM +0800, Sze Howe Koh wrote:
QML is a declarative language
Are you considering sequences of JavaScript statements, especially
+1
N.
Il giorno 24/apr/2014, alle ore 21:15, Attila Csipa q...@csipa.in.rs ha
scritto:
It's a bit tricky. Traditionally, Qt did UIs by mimicking/drawing the UI
elements itself. This is cool, as it's allows for those native looking,
but also super-customizable (and quite fast) UIs. Or,
After playing a bit with Xamarin (yes, I know, but put aside the C# hate for
a minute),
it's quite striking what different approaches can result in (and it also made
it quite clear what Qt is doing better - but also worse than other cross
platform solutions).
Have you elaborated on this
On 25-Apr-14 04:21, Sze Howe Koh wrote:
I consider QML and JavaScript to be different languages. JavaScript
can be embedded into QML to extend QML's capabilities, just like how
it can be embedded into HTML to extend HTML's capabilities.
Yep, I hear people keep repeating the mantra QML is
On Monday 21. April 2014 10.41.52 Christoph Feck wrote:
On Monday 21 April 2014 05:27:33 Joshua Kolden wrote:
I’m curious why you are not interested in QML.
[...]
I see no reason to stay with Qt Widgets at all other than legacy
application support. So what is your concern?
[...]
Not
On Thu, Apr 24, 2014 at 09:47:50AM +0200, Simon Hausmann wrote:
Let's turn this from a blame game into something more productive.
I will simply assume this includes the readiness to re-consider some
of the non-technical decisions of the past.
The nature of the beast is that we do have two
On Thursday 24. April 2014 14.08.03 André Pönitz wrote:
On Thu, Apr 24, 2014 at 09:47:50AM +0200, Simon Hausmann wrote:
Let's turn this from a blame game into something more productive.
I will simply assume this includes the readiness to re-consider some
of the non-technical decisions of
Hi Marius,
On 23 April 2014 23:07, cincirin cinci...@gmail.com wrote:
On 4/23/2014 5:50 PM, Sze Howe Koh wrote:
With QML, the general idea is to use QML for the GUI and use C++ for core
logic.
Well from I understand QML is used in a lot of other aspects than GUI: Qt
WebKit 2 is QML ( only
On 24 April 2014 00:35, André Pönitz apoen...@t-online.de wrote:
On Wed, Apr 23, 2014 at 10:50:23PM +0800, Sze Howe Koh wrote:
QML is a declarative language
Are you considering sequences of JavaScript statements, especially control
flow statements, as declarative?
Andre'
Of course not. :-)
On 25 April 2014 10:20, Sze Howe Koh szehowe@gmail.com wrote:
On 23 April 2014 23:07, cincirin cinci...@gmail.com wrote:
Well from I understand QML is used in a lot of other aspects than GUI: Qt
WebKit 2 is QML ( only ? ), also QML is used in multimedia, position modules
and so on ...
Sorry for re-open this topic, but as someone else already pointed out,
what do you think about the Unreal engine guys to abandon the unreal
script which was used until now for many years ?
To quote some comments:
In the past, gameplay code existed in UnrealScript. UnrealScript is the
scripting
Hi,
On 23 Apr 2014, at 14:14, cincirin cinci...@gmail.com wrote:
Sorry for re-open this topic, but as someone else already pointed out,
what do you think about the Unreal engine guys to abandon the unreal
script which was used until now for many years ?
I don’t think this topic is really
Hi Marius,
On 23 April 2014 20:14, cincirin cinci...@gmail.com wrote:
Sorry for re-open this topic, but as someone else already pointed out,
what do you think about the Unreal engine guys to abandon the unreal
script which was used until now for many years ?
To quote some comments:
In the
On 23 April 2014 22:50, Sze Howe Koh szehowe@gmail.com wrote:
Hi Marius,
On 23 April 2014 20:14, cincirin cinci...@gmail.com wrote:
Sorry for re-open this topic, but as someone else already pointed out,
what do you think about the Unreal engine guys to abandon the unreal
script which was
Hi Sze Howe,
On 4/23/2014 5:50 PM, Sze Howe Koh wrote:
With QML, the general idea is to use QML for the GUI and use C++ for core
logic.
Well from I understand QML is used in a lot of other aspects than GUI:
Qt WebKit 2 is QML ( only ? ), also QML is used in multimedia, position
modules and
On 22 Apr 2014, at 12:49, Simon Hausmann simon.hausm...@digia.com wrote:
On Monday 21. April 2014 15.13.08 Robert Knight wrote:
The design direction is because QML is easier to develop with, more
modern,
and based on OpenGL. Widgets don't have that and will never be as
efficient.
On Wed, Apr 23, 2014 at 10:50:23PM +0800, Sze Howe Koh wrote:
QML is a declarative language
Are you considering sequences of JavaScript statements, especially control
flow statements, as declarative?
Andre'
___
Development mailing list
,
Steve
-Original Message-
From: m...@rpzdesign.com
Sent: Monday, April 21, 2014 12:55 PM
To: Thiago Macieira ; development@qt-project.org
Subject: Re: [Development] Question about Qt's future
Thiago:
I really appreciate your and Intel's participation in the open source Qt
On Monday, 2014-04-21, 11:28:24, charleyb123 . wrote:
...In this case, none of class Cytometer nor class Laser nor class
Wavelength derive from QObject, but we want them exposed to QML.
Including their nested properties. Wrapping-or-deriving-from-QObject is
now required. The Wavelength is
On Mon, Apr 21, 2014 at 02:52:25PM +0200, Roland Winklmeier wrote:
If I want to access this methods from QML I would have to derive them
from QObject and register it in the QML context.
try playing with Q_GADGET instead of QObject/Q_OBJECT - that's much less
heavyweight.
if it doesn't work with
On Monday 21. April 2014 15.13.08 Robert Knight wrote:
The design direction is because QML is easier to develop with, more
modern,
and based on OpenGL. Widgets don't have that and will never be as
efficient.
Therefore, the effort is directed towards the technology that has the
If I want to access this methods from QML I would have to derive them
from QObject and register it in the QML context.
Not necessarily, depends on what you want to do.
However, it is true that it would be nice to have something similar to
QtScript's binding facilities.
On Tuesday 22 April 2014 12:20:58 Oswald Buddenhagen wrote:
On Mon, Apr 21, 2014 at 02:52:25PM +0200, Roland Winklmeier wrote:
If I want to access this methods from QML I would have to derive them
from QObject and register it in the QML context.
try playing with Q_GADGET instead of
Olivier Goffart schreef op 22-4-2014 13:01:
On Tuesday 22 April 2014 12:20:58 Oswald Buddenhagen wrote:
On Mon, Apr 21, 2014 at 02:52:25PM +0200, Roland Winklmeier wrote:
If I want to access this methods from QML I would have to derive them
from QObject and register it in the QML context.
try
On Monday 21 April 2014 05:27:33 Joshua Kolden wrote:
I’m curious why you are not interested in QML.
[...]
I see no reason to stay with Qt Widgets at all other than legacy
application support. So what is your concern?
[...]
Not speaking for Michael, but let me add that C++ is much easier to
On Monday, 2014-04-21, 01:40:50, Michael Knight wrote:
I feel like Qt is going in the direction of being Qml and Javascript only.I
fear that they may abandon Qt Widgets in the near future,I think they are
heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I
want to be
Hi Michael,
In response to your email I have two questions:
1) As your email is addressed to the open source community working on Qt
itself, who are you referring to with they?
2) You are saying that you want to be sure. What kind of assurance are you
looking for?
Simon
Opprinnelig
On Mon, Apr 21, 2014 at 10:53:01AM +0200, Kevin Krammer wrote:
The language barrier between C++ and QML makes it easier to see where UI
ends and program logic begins, leading to better abstraction between core
application and its interface.
The compulsory QML/JS - C++ language cut generates
Roland sayeth:
snip, I liked the design to split business logic into
C++ and UI design into QML and I still like it, but I came across
several blocking issues (some of them are only valid for our
application, some of them are general):
- Our application has a huge framework of value
On 21/04/2014 04:53, Thiago Macieira wrote:
Em dom 20 abr 2014, às 22:37:11, m...@rpzdesign.com escreveu:
Isn't Qt Widgets so mature that they are stable?
They are.
But so much could still be done... as a basic example I stumbled upon
very recently, why is it so hard to change the font of
On Apr 21, 2014, at 6:31 AM, Yves Bailly yves.bai...@laposte.net wrote:
On 21/04/2014 04:53, Thiago Macieira wrote:
Em dom 20 abr 2014, às 22:37:11, m...@rpzdesign.com escreveu:
Isn't Qt Widgets so mature that they are stable?
They are.
But so much could still be done... as a basic
Yves Devs:
I take a different view of tablets. There MANY use cases where tablets
will do a HUGE amount of mission critical *REAL* work
and they will NOT use a keyboard or type 100 words a minute.
But I agree, we need both 100% C++ Qt Widget Option (not using .ui
files) AND QML/js (the new
So we started to design our UI
with QML. I liked the design to split business logic into
C++ and UI design into QML and I still like it, but I came across
several blocking issues (some of them are only valid for our application, some
of them are general):
- Our application has a huge
Em seg 21 abr 2014, às 15:31:57, Yves Bailly escreveu:
QML has its merit, it's certainly perfect for some projects. But for all
I've seen and tried until now, only for projects having a rather simple UI.
For really complex UIs, QML seems not suitable - at least for now.
So our effort goes into
Em seg 21 abr 2014, às 10:59:43, m...@rpzdesign.com escreveu:
Can Qt Widgets design pattern be brought forward using the same OpenGL
foundation
that QML uses to instantiate controls?
Short answer: no.
Long answer: if you want it working in other platforms, without glitches and
regressions,
On Monday, 2014-04-21, 10:59:43, m...@rpzdesign.com wrote:
You can separate the GUI from the Model in C++ Classes as well, not just
in QML/js vs C++ boundary.
Of course. I meant that the boundary makes it more obvious when you are
attemping logic within the UI since you very explicitly switch
Thiago:
I really appreciate your and Intel's participation in the open source Qt
project.
I think you misunderstood what I was talking about and forcefully
rejected that which I did not ask.
I want the pattern brought forward, but we should not try to bring the
code forward. Let sleeping dogs
On Monday, 2014-04-21, 14:15:16, André Pönitz wrote:
On Mon, Apr 21, 2014 at 10:53:01AM +0200, Kevin Krammer wrote:
The language barrier between C++ and QML makes it easier to see where UI
ends and program logic begins, leading to better abstraction between core
application and its
I'm not Roland (talking about value-types), but I completely agree with
his comments on why they are important (we have that issue also).
But, jumping-in, ...
snip, from Roland,
- Our application has a huge framework of value classes. They cannot
(or
at least it does not make sense to)
it again. It's just my
preference and may not be right for everyone.
To Qt's bright future,
Steve
-Original Message-
From: m...@rpzdesign.com
Sent: Monday, April 21, 2014 12:55 PM
To: Thiago Macieira ; development@qt-project.org
Subject: Re: [Development] Question about Qt's future
Michael:
That is a great question.
I hope you get answers that focus on the mobile side of things (IOS/Android)
With Qt 5.3.0 release just around the corner, will Qt Widgets be able to
run stable on IOS and ANdroid?
Many comments I have seen on this list refers to Qt Widgets as a desktop
I’m curious why you are not interested in QML.
I’m just finishing up a an initial production release of software oriented
towards high-performance graphics. We used QML for the interface, coffeescript
for view logic, and Qt/c++ for processing and business logic. It works
astonishingly well
79 matches
Mail list logo
