Re: [Development] Question about Qt's future

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_ (no

Re: [Development] Question about Qt's future

On 28.04.2014 16:00, Roland Winklmeier wrote: > 2014-04-27 13:31 GMT+02:00 Peter Kümmel >: > > 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 n

Re: [Development] Question about Qt's future

> > 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 tr

Re: [Development] Question about Qt's future

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 tha

Re: [Development] Question about Qt's future

2014-04-27 13:31 GMT+02:00 Peter Kümmel : > 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, bec

Re: [Development] Question about Qt's future

On Mon, Apr 28, 2014 at 4:39 AM, Hartmann Thomas wrote: > 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 context/component c

Re: [Development] Question about Qt's future

On 28 Apr 2014, at 9:32 AM, Gunnar Sletta wrote: > > On 28 Apr 2014, at 07:53, Peter Kümmel 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-scenegr

Re: [Development] Question about Qt's future

_ From: 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 f

Re: [Development] Question about Qt's future

lopment@qt-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

Re: [Development] Question about Qt's future

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 > http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph-r

Re: [Development] Question about Qt's future

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 cod

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 "mouse" :-). Could this be a function binding instead?

Re: [Development] Question about Qt's future

On 28.04.2014 09:26, Thiago Macieira wrote: > 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 tra

Re: [Development] Question about Qt's future

s expected? 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 a

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

___ From: development-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] Q

Re: [Development] Question about Qt's future

On 28 Apr 2014, at 07:53, Peter Kümmel 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 http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scene

Re: [Development] Question about Qt's future

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 > >>

Re: [Development] Question about Qt's future

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 fi

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

On 28.04.2014 08:10, Kurt Pattyn wrote: > > >> On 28 Apr 2014, at 07:53, Peter Kümmel 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 "declarati

Re: [Development] Question about Qt's future

> On 28 Apr 2014, at 07:53, Peter Kümmel 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

Re: [Development] Question about Qt's future

On 28.04.2014 00:55, André Pönitz wrote: > 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 be

Re: [Development] Question about Qt's future

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 thos

Re: [Development] Question about Qt's future

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 >>>

Re: [Development] Question about Qt's future

On Mon, Apr 28, 2014 at 6:53 AM, Thiago Macieira wrote: > 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 correct that:

Re: [Development] Question about Qt's future

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++ develo

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

On 27 April 2014 22:31, Mark Gaiser 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 IE6. It's ex

Re: [Development] Question about Qt's future

On Sun, Apr 27, 2014 at 10:37 PM, 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 complaine

Re: [Development] Question about Qt's future

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 y

Re: [Development] Question about Qt's future

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 p

Re: [Development] Question about Qt's future

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 (inclu

Re: [Development] Question about Qt's future

actually end up 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

Re: [Development] Question about Qt's future

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 ___ Deve

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 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 D

Re: [Development] Question about Qt's future

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 Fl

Re: [Development] Question about Qt's future

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 coul

Re: [Development] Question about Qt's future

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++

Re: [Development] Question about Qt's future

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 be

Re: [Development] Question about Qt's future

On Fri, Apr 25, 2014 at 10:21:04AM +0800, Sze Howe Koh wrote: > On 24 April 2014 00:35, André Pönitz 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 > > fl

Re: [Development] Question about Qt's future

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 d

Re: [Development] Question about Qt's future

> 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 t

Re: [Development] Question about Qt's future

+1 N. Il giorno 24/apr/2014, alle ore 21:15, Attila Csipa 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, rather, this use

Re: [Development] Question about Qt's future

On 25 April 2014 10:20, Sze Howe Koh wrote: > On 23 April 2014 23:07, cincirin 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 ... > > Yes, that's true. I think WebKit

Re: [Development] Question about Qt's future

On 24 April 2014 00:35, André Pönitz 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. :-) I was high

Re: [Development] Question about Qt's future

Hi Marius, On 23 April 2014 23:07, cincirin 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 ? ), also

Re: [Development] Question about Qt's future

On 21-Apr-14 18:14, Thiago Macieira wrote: > 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 sui

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

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 lan

Re: [Development] Question about Qt's future

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? > > [.

Re: [Development] Question about Qt's future

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 Development@q

Re: [Development] Question about Qt's future

On 22 Apr 2014, at 12:49, Simon Hausmann 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.> >>> Therefore, the e

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

On 23 April 2014 22:50, Sze Howe Koh wrote: > Hi Marius, > > On 23 April 2014 20:14, cincirin 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

Re: [Development] Question about Qt's future

Hi Marius, On 23 April 2014 20:14, cincirin 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 past, gameplay

Re: [Development] Question about Qt's future

Hi, On 23 Apr 2014, at 14:14, cincirin 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 suited for this list, bu

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

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 conte

Re: [Development] Question about Qt's future

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 Q

Re: [Development] Question about Qt's future

> > > > > 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 b

Re: [Development] Question about Qt's future

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 th

Re: [Development] Question about Qt's future

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 wi

Re: [Development] Question about Qt's future

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 "Wave

Re: [Development] Question about Qt's future

7;ve experienced some pain > with this in the past and I don't want to do 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: Mon

Re: [Development] Question about Qt's future

s in the past and I don't want to do 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

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", ... , > >> - Our application has a huge framework of value classes. They cannot > (or > > >> at least it does not make sense to) derive f

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

On Monday, 2014-04-21, 14:52:25, Roland Winklmeier wrote: > >> - Our application has a huge framework of value classes. They cannot (or > >> at least it does not make sense to) derive from QObject for several > >> reasons. But subclassing QObject is the requirement to access data from > >> C++ in Q

Re: [Development] Question about Qt's future

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 switc

Re: [Development] Question about Qt's future

On Monday, 2014-04-21, 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

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

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 in

Re: [Development] Question about Qt's future

> 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

Re: [Development] Question about Qt's future

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 .

Re: [Development] Question about Qt's future

On Apr 21, 2014, at 6:31 AM, Yves Bailly 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 example I stumbl

Re: [Development] Question about Qt's future

> 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 > potential > to make interfaces for 2017-2020. Unfortunately that

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

Roland sayeth: > , 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 classe

Re: [Development] Question about Qt's future

>> >> - Our application has a huge framework of value classes. They cannot (or >> at least it does not make sense to) derive from QObject for several >> reasons. But subclassing QObject is the requirement to access data from >> C++ in QML. So we had our framework of well designed value classes and

Re: [Development] Question about Qt's future

On Apr 21, 2014, at 4:39 AM, Roland Winklmeier wrote: > Am 21.04.2014 05:27, schrieb Joshua Kolden: >> 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 i

Re: [Development] Question about Qt's future

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 genera

Re: [Development] Question about Qt's future

Am 21.04.2014 05:27, schrieb Joshua Kolden: > 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 process

Re: [Development] Question about Qt's future

Simon Opprinnelig melding Fra: Michael Knight Sendt: 03:45 mandag 21. april 2014 Til: development@qt-project.org Emne: [Development] Question about Qt's future 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

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

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 easie

Re: [Development] Question about Qt's future

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

Re: [Development] Question about Qt's future

Em dom 20 abr 2014, às 22:37:11, m...@rpzdesign.com escreveu: > With Qt 5.3.0 release just around the corner, will Qt Widgets be able to > run stable on IOS and ANdroid? They run. They just look horrible. > Many comments I have seen on this list refers to Qt Widgets as a desktop > oriented toolki

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 orie

[Development] Question about Qt's future

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 sure that they will not abandon C++ side of Qt and that the