Re: [Development] [Announce] Qt 5.7.0 Beta released

[m...@rpzdesign.com]

On 4/25/2016 2:31 AM, Simon Hausmann wrote:


Hi,


Thank you for your feedback.


Could you please elaborate what kind of changes you'd like to see to the QQmlComponent 
API? It is not clear to me what you mean by "compiling loaded QML from a byte 
array".


Similarly, could you please explain what you mean within loading definitions 
into the component cache? Are you referring to the ability to populate the 
component cache on application start up?

Regarding the qmldir files I conceptually agree that it would be nice to get 
rid of them, but it is not an easy task and not a task that I think of being of 
high priority (unless somebody convinces me otherwise). However one thing I 
would like to see as an initial step in the same direction would be to generate 
the content of the files automatically from meta-information for example in the 
build system. Such a step would potentially allow for replacing these files 
with a superior mechanism.

Could you please explain what you mean by an array of plugin bytes?

I also don't see a tight coupling between the QML engine and the network access 
manager. What coupling are you referring to? Is it the ability to compile the 
engine when the network access manager is disabled from the build?

Regarding internationalization support: I invite you to contribute the work 
towards allowing different mechanisms for translations. It would probably make 
most sense if you could attend the Qt conference to discuss the topic in person.


Simon



Simon:

I have a bunch of comments to offer.

Regarding QQmlComponent, The best answer I can give is to suggest different API 
calls:

QQmlComponent.setData( Array of Human Readable QML Bytes )
QQmlComponent.BindImportName("import name","version major","version minor") -> 
Binds an import Name
QQmlComponent.BindLibary("import name", compiled QQuickItem dynamic library) -> 
Binds an import Name  (NO MORE PLUGINS! IOS shared library issues here)

QQmlEngine->CheckForImportCollisions( "import name","version major","version 
minor",QQmlComponent& gcomp)
QQmlEngine->LoadComponentIntoCache( "import name",bla-bla, QQmlComponent& gcomp)
QQmlEngine->UnloadLoadComponentFromCache( "import name",bla-bla)

Possible optimizations:

QQmlComponent.CompiletoByteArray() -> Output an array of "Compiled QML" 
bytecode + dynamic (5.8 QML Compiler but NOT to C++ class files, to bytecode)
QQmlComponent.LoadCompiledByteArray() -> Load a previously Compiled QML 
bytecode into the Component

filename.QML -> normal human readable QML
filename.QMC -> compiled qml byte file

Also, I think the day is fast coming where Qt Creator is no longer viable, only 
the C++ code will have developer value.

Already, you cannot debug QML and C++ on Xcode for simulator/Device.  There are 
severe limitations and the support is tepid at best. Why fight that battle?

Android Studio 2.x series will have integrated C++ NDK debugging along with 
acclerated Java debugging.

Why be content with KDAB 7 episode Jedi Knight series for Android & QT?  Make 
the jump to concentrate QT/Android development inside Android Studio 2.+

Microsoft has its own tools and deprecated Visual Studio 2010/12/13 Plugin and 
QT is scrambling to try to support Visual Studio 2015 with some sort of plugin 
replacement.

My recommendation is that Qt Creator resources be reduced massively to only 
support the Yocto embedded targets on linux.  The rest of the platforms should 
seek to work with native tooling.

Also, the Meta Object compiler needs review because when you open the Qt 
project in XCode, the metaobjects are major human readable problems
yet Xcode is the only environment that can actually debug QT C++ code on 
Simulator and Device. Not Qt Creator.The generated projects need to have 
much cleaner code.

Internationalization should be an open hook that the Qr(" ") is re-factored to 
tap into. Then anybody could tap into the hook with their own internationalization 
mechnanism.  I would like to build the base library without the network manager, but I 
think there are too many links to the network manager header file in GUI.

I would love to come to a conference, but I am just way too busy and have a 
baby on the way, the wife will NEVER let me go to Europe to talk like a geek 
for 4 days.  Every spare dollar
is for domestic operations.

Cheers,

md


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Announce] Qt 5.7.0 Beta released

[m...@rpzdesign.com]

Jani & Tuuka:

There is a reference to the upcoming Qt Quick Compiler in 5.8 in the 5.7 beta 
announcment.

http://blog.qt.io/blog/2016/04/21/qt-5-7-beta-released/

Where do we send input to the people in charge of making 5.8 design decisions?

Since it looks like this is going to a significant re-factor of the base code 
from 5.7, this is the moment to speak up.

I submit that there is a currently a dysfunctional design dependence between a 
5.8 Qt Quick Compiler, the requirement of QMLDIR files for plugins,
the QR("") Internationalization pattern, and QQmlComponent C++ class.

The architecture is cumbersome if you have a project structure that deviates in 
any way from the classic QRC oriented resource files, you do a lot of work.

What I would like to see in 5.8 and beyond.

1)  QQmlComponent as the primary QML interface for C++ developers with the 
QtQuick Compiler optionally compiling loaded QML from a byte array and shipped 
to a customer in the form of downloadable Compiled QML!!!
2) QQmlComponent able to load definitions into the component cache to be used in qml 
"Import MyComponent 1.0"
3) Drop QMLDIR files entirely, they are really stupid.  They have no place in a 
dynamic loadable plugin/component architecture.
4) Allow plugins (either C++ or QML) to be loaded by C++ or 
QQmlComponent.LoadPlugin( array of plugin bytes!, not FILE or URL based!)
Right now I am forced to statically link my plugins into the executable for QML 
to see them and use them. Very clumsy.
5) Decouple the GUI/QML from NetworkResourceManager.  The 
NetworkResourceManager should be an optional component, not required for every 
project.
If you need to download QML using an URL, provide a bridge class to perform 
that.
6) International Support Decoupled (So I can use my own hooks instead of translation 
files in Qr(" ") usage pattern

I really think that if the architecture and cumulative design choices are 
reviewed, you can see a lot of legacy decisions that now can get factored out 
of the design
so there is cleanliness and a proper fit for the Qt Quick Compiler in relation 
to the other QML/C++ constructs.

Thanks for listening,

Marco










On 4/21/2016 4:06 AM, List for announcements regarding Qt releases and 
development wrote:


Hi all,


Qt 5.7.0 Beta is released today, see 
http://blog.qt.io/blog/2016/04/21/qt-5-7-beta-released/


Big thanks for everyone involved!


br,

Jani


Jani Heikkinen
ReleaseManager

The Qt Company
Elektroniikkatie 13
90590 Oulu Finland
jani.heikki...@qt.io
http://qt.io 



  

   




___
Announce mailing list
annou...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/announce


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt bugreports] (QTCREATORBUG-15705) Xcode 7.2 IOS 9.2 Simulator Debugging not possible

[m...@rpzdesign.com]

Eike:

Well, that is a bit of news, thank you for looking at this.

Thank you for your effort in this regard.

md

On 3/3/2016 7:47 AM, Eike Ziller (via JIRA) wrote:

Message Title
	Eike Ziller 
 
*commented* on Bug QTCREATORBUG-15705 



Re: Xcode 7.2 IOS 9.2 Simulator Debugging not possible 



bq Session could not be started: The operation couldn’t be completed. 
(FBSOpenApplicationErrorDomain error 1.)Run ended.Debugging has failed


I cannot reproduce this error message.

The current state with Xcode 7.2 and iOS 9.2 is that debugging C++ on 
iOS from Qt Creator only works on device, and debugging QML only works 
on simulator.
As a workaround please either debug C++ from Xcode, or on device (and 
QML on simulator).
Unfortunately Apple does not provide any official APIs for debugging, 
so what Qt Creator does to try to pull it off is very fragile by nature.


Add Comment 
 	Add 
Comment 


This message was sent by Atlassian JIRA (v6.3.9#6339-sha1:46fa261)  
Atlassian logo



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.7 feature freeze postponed, new date to be agreed

[m...@rpzdesign.com]

Tuuka:

I was looking around for "Coin CI" information on google.

Can you provide links and additional insight into this CI?

We have a thread on the interest list related to CI.

md


On 12/9/2015 9:58 AM, Turunen Tuukka wrote:


Hi,

15th Jan sounds good to me as the new FF time for Qt 5.7. The idea is 
to have the currently TP modules (at least many of them) supported 
with Qt 5.7 and also to drop the non-C++11 compilers as already 
discussed, agreed and implemented for dev. Therefore the content of Qt 
5.7 is to a large extent already shaping up and in case someone has 
new features just starting, these are probably better to aim towards 
Qt 5.8. I really would like us the finally get to the desired April & 
October release cycle during 2016 with the new Coin CI. Even though 
moving Qt 5.7 FF to 15^th Jan means the final being in May instead of 
April, I think it is something we can accept.


Yours,

  Tuukka

*From:*Development [mailto:development-boun...@qt-project.org] *On 
Behalf Of *Heikkinen Jani

*Sent:* keskiviikkona 9. joulukuuta 2015 12.22
*To:* development@qt-project.org
*Subject:* [Development] Qt 5.7 feature freeze postponed, new date to 
be agreed

*Importance:* High

Hi all,

According to original plans we should have Qt 5.7 FF next Friday (18th 
Dec). But we are still fighting to get Qt 5.6 (beta) out so there is 
no point to start freezing Qt 5.7 yet. We discussed about that 
yesterday's release team meeting & agreed to start discussion in ML 
about the issue. Ideally we should wait Qt 5.6.0 RC before start 
freezing Qt 5.7. But waiting Qt 5.6.0 RC might cause unnecessary delay 
for Qt 5.7 as well and I don't want to postpone 5.7 so much. That's 
why I propose 15th Jan 2016 for new feature freeze date for Qt 5.7. It 
should be quite near Qt 5.6.0 RC (if we managed to get Qt 5.6.0 out 
during next week as planned).


br,

Jani



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QTBUG-46552 : QUdpsocket bug always present on 5.5.1 RC on Mac

[m...@rpzdesign.com]

Can you provide a sample project to reproduce this?



On 9/24/2015 5:37 PM, qt next wrote:
> Hi,
>
> I have tryed the RC1 for the 5.5.1 and it seems that I can always
> reproduce the bug 46552, at least on mac platform.
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

-- 
No spell checkers were harmed during the creation of this message.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to speed up QML for KDE5 without QML compiler

[m...@rpzdesign.com]

Ulf:

Can you explain that a little more.

Loaders trade startup delay for runtime cost.

What are the units of measure for runtime cost?

I am having trouble plotting in my mind how to plot the tradeoff.

As startup delay goes up, does runtime cost go down?

Thanks,

md

On 9/16/2015 5:15 AM, Ulf Hermann wrote:
> Hi,
>
> Use the QML profiler in Qt Creator to find out what exactly is slow. Use 
> loaders, but don't overuse them. Loaders trade startup delay for runtime 
> cost. You should decide what is worse depending on your application.
>

-- 
No spell checkers were harmed during the creation of this message.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Announce] Qt Creator 3.5.0 released

[m...@rpzdesign.com]

This may sound stupid but is there an easy way to have the Kits get 
automatically detected when you run the Qt Creator 3.5.0?

I was running Qt Creator 3.4.2 before this from the Qt 5.4.2 installation.

Manually adding kits is kind of a pain.

md

On 8/20/2015 7:03 AM, List for announcements regarding Qt releases and 
development wrote:
 We are happy to announce the release of Qt Creator 3.5.0!

 http://blog.qt.io/blog/2015/08/20/qt-creator-3-5-0-released/


-- 
No spell checkers were harmed during the creation of this message.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qqmlengine/qqmlimport access

[m...@rpzdesign.com]

Robin:

I am fairly new to the process, and just eyeballing the source trees 
does not give me a working understanding how the render thread and the 
GUI thread play nice together.

So knowing the point at which to add a call to int 
QQmlEngine::addComponent(QByteArray gbqml,QString gsimportname) that will:

A) gracefully load the component async/sync
B) add it to the component cache async/sync
C) add the import name to the imports list of known types
D) all while not breaking the choreography of QML GUI and QSG scene graph.

I certainly do not want to add code that blocks the QSG!

Or memory access at just the wrong time causing the buffers to become 
corrupted.

There is a lot going on in there, like WebEngine overlays, video surface 
underlays, etc.

Does that address the lack of clarity?

Thanks,

md


On 6/9/2015 3:43 AM, Robin Burchell wrote:
 On Tue, Jun 2, 2015, at 11:44 PM, rpzrpz...@gmail.com wrote:
 Another concern I have is the Render Thread issues VS Gui thread issues.

 Can you elaborate on this concern? The current description is impossible
 to address, which might explain the lack of response.


-- 
No spell checkers were harmed during the creation of this message.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qqmlengine/qqmlimport access

[m...@rpzdesign.com]

Simon:

I just finished reviewing the QQuickImageProvider framework
and that might also be an known interface pattern acceptable to the team.

Component { source: memory://myqmlprovider/myqmlcomponent }

And it may just fit nicely into the current qrc: pattern.

Just my 2 cents...

md

On 6/9/2015 1:02 AM, Simon Hausmann wrote:
 On Tuesday, June 02, 2015 03:44:59 PM rpzrpz...@gmail.com wrote:
 On 5/29/2015 9:53 AM, mark diener wrote:
 Hello dev list:

 Qt 5.4.1.

 At the top of qqmlimport_p.h, it discusses how it is NOT part of the QT
 API and subject to change.

 In qqmlengine.h, there is addImportPath( ) to allow qqmlimport to
 resolve types using a module/qmldir file.

 But ByteArray derived components have no equivalent treatment:


 QByteArray  gbytes(import  QtQuick  2.4\n  Rectangle  {
 objectName:\myRecto\\n  color:  \blue\  });

 QQmlComponent  gcomponent(gengine)  ;

 gcomponent.setData(gbytes,QUrl(Myrectangle.qml));


 How to add the QQmlComponent in the QQmlEngine import database so that
 QQmlImports::addImplicitImport( ) can resolve component type?

 There is no new C++ type here, just a new component defined in QML, so
 qmlRegisterTypeC++type(bla,bla,bla) is a fail.

 Or maybe there is a non-qmldir file method to use importExtension with
 QQmlComponent?  (qmldir file alternative)

 Does QQmlEngine have a public access way to achieve the following:

 QQmlEngine::addImportComponent(QString gname,QQmlComponent gcomponent) ;
 QQmlEngine::removeImportComponent(QString gname) ;

 In QML, I could either have an importExtension()  OR an implicitImport()
 in qqmlimports.

 Thanks,

 Mark

 Simon:

 I think the absence of responses from the dev list indicates I have
 touched on a topic dead zone that resides in your area as QML/core
 maintainer.

   From what I can tell, the QML component cache and import mechanisms
 lack any public access members for direct query,loading, and removal.

 Yes.

 There are the blunt force methods of QQmlEngine-clearComponentCache()
 and QQmlEngine-trimComponentCache().

 Maybe after the 5.5 release, I would like to explore adding public
 access member functions to QQmlEngine.h/cpp:

 int QQmlEngine::loadComponent(QQmlComponent component, QString
 importQmlName);

 int QQmlEngine::clearComponent(QString importQmlName);

 bool QQmlEngine::isComponentLoaded(QString component);

 The biggest concern I see is the caveat warnings given by qqmlimport.h

 I'm wondering what the specific use-cases are. More specifically what criteria
 would be used to call these functions?

 If you'd like to pre-load components, then I agree that we could have
 dedicated API for this, although you can already do this today by creating an
 async QQmlComponent and just not call create() on it.

 Another concern I have is the Render Thread issues VS Gui thread issues.

 What group of devs is current this?

 Does that group even talk to strangers?

 Hehe.


 Simon
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


-- 
No spell checkers were harmed during the creation of this message.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Q_INVOKABLE QAbstractListModel

[m...@rpzdesign.com]

Konstantin  Olivier:

I though this unknown base type might be missing from the meta compiler
and thus not the framework recognizing AbstractList* but recognizing 
many other types.

But there is a RegisterType option to make this all go away.

Lightbulb going off right now

Thanks to you both,

mark
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Q_INVOKABLE QAbstractListModel

[m...@rpzdesign.com]

Konstantin:

Maybe you could add some useful guidance to your response.

The point of interest is that it must be a QObject derived return.

Maybe a pointer to a QObject.

Or maybe there is another way to construct QAbstractListModel that will 
allow for a non-pointer return from Q_INVOKABLE?

(But that would be on the stack likely)

More comments appreciated,

mark

On 5/23/2015 11:38 AM, Konstantin Ritt wrote:

 2015-05-23 21:20 GMT+04:00 mark diener rpzrpz...@gmail.com
 mailto:rpzrpz...@gmail.com:

 Hello:

 I came across a use case where I wanted to return a
 QAbstractListModel from
 a Q_INVOKABLE in a C++ QObject based class.

 The explicit constructor for QAbstractListModel requires a
 construction of these classes that forces the Q_INVOKABLE to return
 a pointer to the List Model instance.

 I imagine the explicit constructor suppresses a lot of careless bugs.

 But this usage is not currently possible:

 Q_INVOKABLE MyQAbstractListModel*  getmodel(void)

 {

 return  (gmodel)  ;

 }


 The QML engine is a bit confused by receiving a pointer to the model
 instead of the entire model itself.

 QML Output:

 qrc:/main.qml:48: Error: Unknown method return type:
 MyQAbstractListModel*


 Maybe someone on the dev list has an idea on how to return a pointer
 to a model from Q_INVOKABLE or maybe someone doing current builds
 can add a AbstractListModel pointer to the known set or method
 return types in the framework for Qt 5.5.x

 Anybody's comments appreciated...


 http://doc.qt.io/qt-5/qtqml-cppintegration-topic.html



 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development






___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 5.4.1 OSX macdeployqt FAIL

[m...@rpzdesign.com]

Thiago:

My intention was never (explicity or implied) to insult anyone.

Now I know who the platform maintainer is!

https://wiki.qt.io/Maintainers

And how Mr Sorvig could take offense!

And for that I share my sincere apology for any offense.

md


On 5/11/2015 12:43 PM, Thiago Macieira wrote:
 On Monday 11 May 2015 11:02:47 m...@rpzdesign.com wrote:
 There is a huge amount of code and build infrastructure to learn just to
 get to a minimum level of competence on Qt 5.x.

 --- I nominate you for “most drama in bug report” in this year’s awards.

 Well, since you mention it, I nominate Sorvig for “best Qt community
 builder” in this year’s awards for having such a positive attitude
 and sharing so generously.

 This discussion is not useful, so please stop, both of you.

 Mark, you fell through a narrow corner case that no one had tested. We
 understand your frustration, but the best way to get help is with honey, not
 vinegar: post a comprehensive bug report and avoid insulting people
 (explicitly or implied).

 Morten, please count to 10 before replying to an email that angered you. Or go
 for a snack attack. Then reread your email for tone. We're trying to create an
 attractive community for our users and we also do that with honey not vinegar.

 Anyway, the patch is approved and will be in Qt 5.5.


-- 
No spell checkers were harmed during the creation of this message.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 5.4.1 OSX macdeployqt FAIL

[m...@rpzdesign.com]

Sorvig:

There is a huge amount of code and build infrastructure to learn just to 
get to a minimum level of competence on Qt 5.x.

--- I nominate you for “most drama in bug report” in this year’s awards.

Well, since you mention it, I nominate Sorvig for “best Qt community 
builder” in this year’s awards for having such a positive attitude
and sharing so generously.


On 5/11/2015 4:11 AM, Sorvig Morten wrote:

 On 11 May 2015, at 08:45, Ziller Eike eike.zil...@theqtcompany.com wrote:


 On May 10, 2015, at 9:08 PM, mark diener rpzrpz...@gmail.com wrote:

 Well, it looks like the big weakness in OSX deployment is macdeployqt and 
 we are on version 5.4.1+

 I was able to change my macdeployqt command line FROM:

 macdeployqt ./testdep.app/ -qmldir=/macdev/qdev/testdep/ -verbose=2 enter

 TO:

 macdeployqt testdep.app/ -qmldir=/macdev/qdev/testdep/ -verbose=2 enter

 And it WORKED!

 The only difference between the two is the period and forward slash in 
 front of the testdep.app reference.

 I think it should be registered with the maintainer of macdeployqt that the 
 tool is subject to falling down on its knees
 with just the slightest syntax variation. YIKES!

 I nominate you for “most drama in bug report” in this year’s awards.

 Anyway, let’s fix it! It’s a one-line patch:

 https://codereview.qt-project.org/#/c/112054/

 Morten :)
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


-- 
No spell checkers were harmed during the creation of this message.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to have equivalent of function over-riding in Qml

[m...@rpzdesign.com]

Please do share when you get to the bottom of this.

md

On 7/10/2014 8:55 AM, travik wrote:
 Ok!. That's cool and it is Qml's implementation of VTable, I guess!.
 Thanks a lot again. Let me try it and come back.
 
 
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request for a sandbox area: Replicant

[m...@rpzdesign.com]

This cross process stuff is starting to feel like 1996 and
remote procedure RPC calls, now using QT signals and slots. drool
again for effect.

One could review the history of microsoft and the fine RPC mechanisms
that turned out to be mostly unusable, or maybe just unused.

Keep the optimism in check folks. We have a lot of devices now in the
mix, not just Win32.

md


On 6/1/2014 6:50 PM, Stottlemyer, Brett (B.S.) wrote:
 I am *HUGELY* interested in this.  We do lots of IPC, and across physical 
 devices, 
 and his design issues really hit home for us.  Part of the reason for our 
 interest 
 is we've implemented similar things, and the design-approach-overlap is 
 uncanny.  (That's a CAN bus joke.)

 …

 This is plumbing.  It should be in a library.  Sitting on top of Qt. 
 Providing 
 simple type-safe cross-process messaging.

 Signals/slots transparent across processes... drool...

 --charley
 
 \o/
 
 Thanks, Charley!  No pressure, though, right?
 
 Brett
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request for a sandbox area: Replicant

[m...@rpzdesign.com]

Bret:

I am certainly open to Ford Motor Company sponsoring my flight to
wherever this summit is taking place and we can dispose of the problem
of my failure to attend.

My talk would be titled, How Bill Gates dreamed of using RPC to court
his future yet unseen wife

Hell, that might even be qualify for a TED talk as well.

I promise I will buy you a beer when I land.

My usage of the term HELL probably indicates that I am a crude
American without the fine polish of our European counterparts, like our
allies at Digia, with whom I have true respect.

To put it into automotive terms, I likely drive a F-150 and not a Prius.

But I will continue with this monologue until they cut me off.

There is the local case and the remote case across the myriad number of
devices.  There are just a lot of extra variations in IPC across
Desktop, Android, and IOS.

For example on Local: http://www.slideshare.net/jserv/android-ipc-mechanism

For Remote, I think you are left with UDP broadcast/multicast for
discovery/reconnection purposes.

The reason why RPC died and HTTP/REST dominates is the simple fact that
HTTP/REST is SIMPLE.  Not 10 million bloody incomprehensible parameters
like RPC.

Whey does SOAP continue to decline?  Extra complexity for little or no
gain.  Who wants to worry about WSDL?

With HTTP/REST, If you do not have network connectivity, the ergonomics
are dictated by a simple timeout and an HTTP/404 error or something like
that.

WIth RPC, you could NEVER tell why it was not working.  But you were
SURE it was NOT working.  Sometimes, you were not sure it WAS working.

Let alone a human being operator getting meaningful feedback
and the library supporting such simple feedback.

What does error WM_ERRORBASE+IPCERRORBASE+CUSTOMIPCERROR mean?

So be very careful in getting distracted by all the IPC unification work
just to make replication function across device platforms.  There may be
an easy alternative for both local and remote cases.

I know, I use UDP broadcast for both Android and IOS because it just
works. And the code is SIMPLE.

Cheers,

md
San Vito
Costa Rica





On 6/1/2014 8:30 PM, Stottlemyer, Brett (B.S.) wrote:
 This cross process stuff is starting to feel like 1996 and remote procedure 
 RPC 
 calls, now using QT signals and slots. drool again for effect.

 One could review the history of microsoft and the fine RPC mechanisms that 
 turned out to be mostly unusable, or maybe just unused.

 Keep the optimism in check folks. We have a lot of devices now in the mix, 
 not just Win32.
 
 LOL.  
 
 I understand this is a proposal and is code you've never seen.  So it is 
 impossible for you to tell, based on my description, if it actually does any 
 of the stuff I say it does.  It could be the killer app Charley is looking 
 for, or a total who cares as you seem to.
 
 I am going to QtCS to talk about it, and I'm sure I will be addressing 
 concerns like yours.  /me wonders what Thiago's first question will be
 
 BUT - unless you are going to be at QtCS, I'd appreciate it if you took the 
 time to express what you think Replicant needs to do to be successful, or at 
 least what you think caused other RPC mechanisms to fail  While I 
 understand the sentiment, it would be helpful to understand what you think 
 Replicant can do to keep falling into the same trap.  Or are you of the 
 opinion that an easy/sound RPC mechanism isn't possible?
 
 Thanks,
 Brett
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request for a sandbox area: Replicant

[m...@rpzdesign.com]

What we really want to know Charley is whether you drive a F-150 or a
Prius.  That will decide whether this is a Killer App.

md

On 6/1/2014 9:43 PM, charleyb123 . wrote:
 This cross process stuff is starting to feel like 1996 and
 remote procedure RPC calls, now using QT signals and slots. drool
 again for effect.
 
 One could review the history of microsoft and the fine RPC mechanisms
 that turned out to be mostly unusable, or maybe just unused.
 
 Keep the optimism in check folks. We have a lot of devices now in the
 mix, not just Win32.
 
 
 I understand your assertion.  By 1996 I'd already completed multiple
 CORBA projects for the telecom and aviation industries.  You're right --
 it was largely unusable.  Hence, those technologies are pretty much gone
 now (too expensive and problematic).
 
 That era had problems:
 
 (1) Too complicated (security, platforms, versioning, etc.)
 (2) Really big foot print.
 (3) Really expensive tooling (pricing, and hardware requirements)
 (4) Profound invasiveness/coupling across the tiers
 (5) Non-scalable (real-world designs could not evolve without profound
 cost or rewrite, despite promises to the contrary)
 (6) Inability of the standard to be implemented (it was massive)
 (7) Inability of the tools/libraries/APIs/standards to evolve (the
 standard and industry variants were too big/complicated)
 
 So, everybody shifted to lighter stuff, like RPC/SOAP/RMI/REST.
 
 However, these don't solve the fundamental issue:  Asynchronous
 type-safe messaging across processes.
 
 Fundamentally, you can't have it.  (Not today, with current approaches;
 you have to roll-your-own.)
 
 I agree that today's lighter fare (like HTTP/REST) is better than
 back-then.  However, that means you have to serialize to XML or JSON,
 and do your own marshalling to/from your higher-order types.  Yes, it's
 simple. But, it's tedious. The first thing any sane person would do is
 wrap (hide) that detail so the system doesn't see it.  That's why I
 want the library.
 
 Today's assertion is more specific:  Cross-process and cross-hardware
 scaling requires:
 
 (a) Asynchronous/non-contention (i.e., messaging designs)
 
 (b) Type-safe APIs (beyond POD, handling data marshalling)
 
 The signals/slots approach is a new variation over the past, and over
 what's widely used today.  IMHO it is an elegant approach (Qt users
 already design for (a)  (b) when we do signal/slot).
 
 Don't make me define a schema.  If I pass a QVariant to another process,
 it had better show up as a QVariant.  If you make me define an XML/JSON
 schema, I'll do it as an implementation detail, but I won't tell anyone
 about it (because I own both ends).  If I want to give a customer
 access to one end, I'll give them a library that lets them work with
 real-types and which handles internal control flow/timing details, and
 not an out-of-date JSON schema description.  That's why this should be a
 library.
 
 A generalized solution is possible here.  That's why I'm saying
 killer app.
 
 Yes, the downside is that I need Qt on both ends -- so a QVariant is
 sent and then received (through signal/slot).  However, this is
 *also* why it offers benefits that today's other technologies cannot
 match (transparent serialization and notification).  But, since we
 already use Qt as our cross-platform porting layer, IMHO this is a
 feature.
 
 True, large distributed systems may need other things like network
 topology management (nodes come-and-go, security, etc.), but IMHO
 that's pretty secondary and not terribly difficult to scale on top of
 the premise/approach, which is type-safe cross-process messaging.
 
 The reason why RPC died and HTTP/REST dominates is the simple fact that
 HTTP/REST is SIMPLE.  Not 10 million bloody incomprehensible parameters
 like RPC.
 Whey does SOAP continue to decline?  Extra complexity for little or no
 gain.  Who wants to worry about WSDL? 
 
 With HTTP/REST, If you do not have network connectivity, the ergonomics
 are dictated by a simple timeout and an HTTP/404 error or something like
 that.
 WIth RPC, you could NEVER tell why it was not working.  But you were
 SURE it was NOT working.  Sometimes, you were not sure it WAS working.
 Let alone a human being operator getting meaningful feedback
 and the library supporting such simple feedback.
 What does error WM_ERRORBASE+IPCERRORBASE+CUSTOMIPCERROR mean?
 
 
 These are fair points.  I separate the two:
 
 (1) Ease-to-use:  Signals/slots across processes is hands-down
 superior in every way than anything listed above.  (Simpler, more
 correct, more elegant, easier to scale.)  -- If it works.
 
 (2) Ease-to-setup/administer:  I don't know yet.  This will be an
 important detail.  I think this is consistent with your concern above,
 which is one of the reasons HTTP/REST is so popular now (it's easy to
 setup and diagnose).
 
 So, I concede you raise good points.  However, if 

Re: [Development] Bringing Qt's high-dpi support to more platforms

[m...@rpzdesign.com]

Morten:

Hopefully you are going to developer days in Berlin this summer.

And Hopefully you are giving a presentation that will be available on
youtube titled, Qt Quick Developer Quick Start to developing QML Opengl
Core Graphics Code for Android and IOS on 5.3+

I think you guys who are veterans of the foundation code could give us a
quick start instead of having to feel my way through the classes and code.

For example, I did not know how to build Qt static until I watched:

https://www.youtube.com/watch?v=chMNUzpN4pw

That video saved me HOURS of trial and error trying to understand the
process.

I would love to see what tips and tricks the experienced developers have
when arranging their build and debug environments in Windows and OSX
that you have found works back in Finland.

It would be nice to be able to start contributing code at some point
when I have a new device like the SUPER HDPI Android 8.9

Cheers,

marco

On 5/26/2014 8:51 AM, Sorvig Morten wrote:
 
 On 26 May 2014, at 07:59, Ziller Eike eike.zil...@digia.com wrote:
 

 On May 23, 2014, at 6:03 PM, m...@rpzdesign.com wrote:

 Sorvig:

 From the latest new front:

 http://bgr.com/2014/03/18/nexus-9-specs-details/

 Digitimes on Tuesday cited its own research arm in reporting that Google
 will launch two new Nexus tablets in 2014. In addition to an updated
 Nexus 7, Google is reportedly prepping a new 8.9-inch Nexus tablet that
 will feature a Retina-busting screen with better-than-2K resolution.

 So will your HIGH DPI modification support the coming high res Android
 stuff too?

 The retina support that currently is in Qt/Mac (which would be extended to 
 the other platforms) supports any float scale factor for HiDPI.
 
 .. with the qualification that Mac always uses an integer scale factor (2x) 
 and that you might get painting artifacts with a non integer factor. WinRT is 
 are using float scale factors so this will see testing there. High scale 
 factors should not be a problem in itself, what I see from testing on desktop 
 is that the style breaks at some point going beyond 2X.
 
 Android support itself is still on the TODO list.
 
 Morten
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Bringing Qt's high-dpi support to more platforms

[m...@rpzdesign.com]

Thiago:

Maybe you could broach the subject at the contributors summit that maybe
the group could share in a public way best practices and lessons learned
so others can jump into a build/debug contributory role quicker.

I recently reported a bug to the QT bug tracker and the very nice people
at Digia responded very quickly, eager to try to find the bug,
essentially saying, Community, you document and submit reproducible
bugs and we will fix them.

But I like the idea of being able to run my own building/debugging and
submitting fixes to the community as well.

So all the devs likely have lots of tips and tricks that they have
gleaned over the years for setting up a build and test environment on
both OSX and Windows.

Thiago, you likely have tons of brilliant build/debug choices that you
now perform automatically with the QT code base.

What I unfortunately do not have is a budget to support self-learning
on how to gain contributor proficiency with the million lines of QT code
base.

I cannot even find a coherent Qt 5.3/Qt Quick 2.0 Class Diagram to begin
to organize it in my mind.

The online build/debug documentation is not accessible enough for me
just yet to efficiently get to contributor speed.

Also, maybe I missed the unit test files, but I did not see them when
scanning the code base.

Many thanks for your concise and competent answers Thiago,
Intel deserves kudos for sponsoring QT with your service.

Cheers,

Marco


On 5/26/2014 12:13 PM, Thiago Macieira wrote:
 Em seg 26 maio 2014, às 09:04:28, m...@rpzdesign.com escreveu:
 Hopefully you are going to developer days in Berlin this summer.

 And Hopefully you are giving a presentation that will be available on
 youtube titled, Qt Quick Developer Quick Start to developing QML Opengl
 Core Graphics Code for Android and IOS on 5.3+
 
 The Contributor Summit is technically still Spring (2 weeks from today) and 
 no 
 sessions get recorded. The Developer Days are in the Fall (October) and 
 that's 
 when sessions are recorded.
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Bringing Qt's high-dpi support to more platforms

[m...@rpzdesign.com]

Sorvig:

From the latest new front:

http://bgr.com/2014/03/18/nexus-9-specs-details/

Digitimes on Tuesday cited its own research arm in reporting that Google
will launch two new Nexus tablets in 2014. In addition to an updated
Nexus 7, Google is reportedly prepping a new 8.9-inch Nexus tablet that
will feature a Retina-busting screen with better-than-2K resolution.

So will your HIGH DPI modification support the coming high res Android
stuff too?

Cheers,

md


On 5/23/2014 3:20 AM, Sorvig Morten wrote:
 Over the past year-and-a-half we’ve implemented high-dpi scaling for Qt on 
 Mac OS  X and iOS. Now we have an excellent opportunity to bring this support 
 to other platforms.
 
 A quick recap for those unfamiliar: This high-dpi mode is an alternative to 
 the traditional DPI scaling. In the traditional approach the application is 
 presented with an DPI value used to multiply font sizes, layouts etc. In the 
 new mode the operating system provides Qt with a scale factor which is used 
 to scale graphics output: allocate larger buffers and set a scaling transform.
 
 The advantage of this approach is that that vector graphics and fonts scale 
 automatically and existing applications tend to work unmodified. Raster 
 content handling is a neutral point - the app author needs to provide 
 high-resolution artwork but this is manageable. A typical disadvantage is 
 confusion caused by the existence of two coordinate systems: “Are these style 
 hints in device independent or device pixels? 
 
 Looking at other platforms:
 
 - WinRT: Already uses high-dpi scaling as of change aeea02ff10 .
 
 - Wayland: Version 1.2 added wl_output::scale, which we can use. This change 
 implements high-dpi scaling for the backing store:
 
 https:/codereview.qt-project.org/#change,63600
 
 -  Platform independent support: We can bring high-dpi support to any 
 platform by adding a coordinate translation layer to QWindow and 
 QWindowSystemInterface and making minor modifications to the platform 
 plugins.  See the following changes:
 
 https://codereview.qt-project.org/#change,86107
 https://codereview.qt-project.org/#change,86108
 
 Some preliminary testing has been done with the XCB platform plugin:
  * KDE Frameworks 5: http://imgur.com/a/JhXSX#sUGYZmB
  * Qt Creator: http://i.imgur.com/EEwdPTD.png
 
 This also allows testing any scale factor on any hardware by setting an 
 environment variable.
 
 
 Adding support to QtWayland looks like a win to me. Do we want to add 
 platform-indepent support to Qt?
 
 Morten
 
 
 
 
 
 
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[m...@rpzdesign.com]

Thomas  Tero:

There is no way that I can make it to the contributors summit, but
Thomas' message might be a important discussion pience when you arrive
in Berlin.

Related to points 5,6,7 of Thomas' message Below:

Is there a class diagram on the current code base?

This would help newbies when trying to contribute to the refactoring
strategy.

The code supporting the QML, JS, and C++ must be layered and sensibly
separated so that people can opt-in on various parts at compile/link time.

When respected people like Thiago Macieira put forth the idea that
there is no public API at the C++ level for Scene Graph and other QML
locked in design pieces, that does not smell right.

Where are the unit tests and test benches for the Qt code base?

I have not seen a script that runs the test bench/unit tests for this
large QT code base.  Anybody have insights on that?

Thanks,

Marco


On 4/28/2014 3:26 AM, 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 translation from QML to a .ui file could be a first step? That
 could work if you use QtWidgets in the QML file.
 I think we should start on top of the C/C++ part of current QMLv2
stack (if
 such a thing exists), with some handwritten widget code. Otherwise we
have
 a QPainter based system which we already have with QWidgets.

 Forget about QPainter.

 Your first step, it seems to me, would be to add the necessary C++
public API
 to QtQml so you can instantiate new items in the QML graph, then
manipulate
 their properties and bindings, as well as set new JavaScript code and
 expressions. This simply replaces the QML parser, keeping all the
benefits (and
 problems) of the QML language. In particular, it does not extricate
the JS
 interpreter and engine.

 If you want to extricate the JS engine, you probably need to move the
Scene
 Graph classes out of QtQuick and into a module that depends only on
QtGui,
 bypassing the QtQml dependency. You'll need a way to insert generic
items into
 the graph. But, at this point, I question: why don't you just use an
existing
 OpenGL scene graph, like Ogle3D?

 Once you've got the base API, you can start thinking of writing
widgets again,
 the platform look and feel. If the QtQml dependency was maintained, it
might
 be possible to reuse the code from Qt Quick Components. If not, you'll
 probably need to start from scratch.



On 4/29/2014 3:43 AM, Hartmann Thomas wrote:
 Hi,
 
 On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz apoen...@t-online.de wrote:
 I think at least three modifications are inavoidable: For one, things that
 could be written in a declarative way but which currently are only possible
 using JavaScript, a declarative way should be added. Second, it should be
 stressed in the documentation (including the examples), that using
 inline imperative code is naughty. This can be supported by e.g. the QML
 Designer refusing to operate on such files. People can still do that, but
 would be on their own. And finally, and that's also acting as a proof that
 the first two items actually have been done, the JavaScript dependency
 should be _optional_.
 
 Can we turn this into action points we _all_ agree on?
 My personal favorites are (In no strict order):
 
 (1) Identify non declarative parts of Qt Quick and add declarative API (e.g. 
 setting states)
 (2) Document that inline Java Script and mixing declarative and imperative 
 code in one file has its pitfalls in big projects and creates issues for 
 tooling. Explain the difference between pure declarative QML and QMLJS and 
 the impact on tooling.
 (3) Document that accessing ids from other .qml files without any interface 
 (just relying on the fact that they are in the context) creates hard to 
 maintain QML code.
 (4) Writing (more) QML(JS) static analyzers that can check/enforce a proper 
 strict mode for QML.
 (5) Write refactoring tools that help to clean up existing code.
 (6) Fix/cleanup existing demos and examples.
 (7) Investigate how we can improve the interplay of QML and C++. Especially 
 in C++/backend heavy projects.
 
 As a second step the actual work has to be done of course.
 
 Kind Regards,
 Thomas Hartmann
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[m...@rpzdesign.com]

After 10 years, time to refactor to
organize the stack.

md

On 4/28/2014 6:02 PM, Thiago Macieira wrote:
 Em seg 28 abr 2014, às 23:34:21, André Pönitz escreveu:
 On Mon, Apr 28, 2014 at 11:12:47AM -0700, Alan Alpert wrote:
 Yes, I agree that more rigorous and agreed definitions would be
 helpful. It also takes time, and impedes innovation, so I'm not sure
 if we're quite mature enough to nail down QML just yet. Should be
 soon though, in the next few years.

 To get this straight: After five years of development the Maintainer of
 the Qt Declarative module is neither able nor willing to give a simple
 definition of what QML is.
 
 I can't also explain very well what QtCore is and it has existed for 10 years 
 now.
 
 It's the low-level interface to the OS and basic and tool classes, plus a 
 part 
 of the XML support, but not all of it. And the item models. And the state 
 machine. Oh, and a few more tidbits that ended up in QtCore because they are 
 not really graphical in nature.
 
 So is QtCore the kitchen sink?
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about Qt's future

[m...@rpzdesign.com]

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 .ui file replacement) for 2017-2020 future.

You can separate the GUI from the Model in C++ Classes as well, not just 
in QML/js vs C++ boundary.

Qt Widgets are currently stable and they work.  (Ignore cosmetic/native 
looking issues- I want program to look SAME across all tablets)

Can Qt Widgets design pattern be brought forward using the same OpenGL 
foundation
that QML uses to instantiate controls?

Peeking at the documentation, QQuickWindow is the container for the 
scenegraph, which has a bunch of
QQuickItems.

Why can't a single QQuickItem == Future Qt Widget?

Any QT Devs expert in the QQuickWindow implementation care to chime in 
on mapping the Qt Widget concept
into the new scenegraph architecture?  (100% C++ GUI, 100% C++ 
Model/Controller)

Obviously, the future QtWidget will have a different pattern than 
current Qt Widget.

Thanks for the lively Monday Qt Future discussion even if Finland and 
Norway are on Holiday!

Cheers,

md


On 4/21/2014 9: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 stumbled upon
 very recently, why is it so hard to change the font of *one* item in
 a combo box??

 The design direction is because QML is easier to develop with,
 Not for heavy-weight applications, even less when part of the UI is
 dynamically build at runtime according to context, config files, etc.

 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.
 Even in 2017-2020, we'll still have desktops. Phones or even tablets are just
 not suited for *real* work, and I don't see how they could be. A professional
 writer can type 100 words per minute on a keyboard, I doubt this will be
 even remotely possible on a tablet. Doing serious 3D modeling on a tablet
 is a joke. And think about the hundreds of mouse/keyboards shorcuts... if
 you remove them, as its the case on modern devices, you loose a lot in
 productivity.

 QtCreator is a complex application, though not as heavy-weight as some I
 work on. Could it be redone the right way, with *all* the UI in QML and
 the business logic in C++? would developing QtCreator this way be as 
 efficient
 as it is today? and finally, would a user be as efficient with it on a
 modern device as he can be on a good'old desktop? Same question for Calligra
 and others.

 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.

 Mind, what I (and others) is talking about, are applications where user's
 productivity matters more than the UI being nice - or even looking native.
 Take Blender: sure, the learning curve is steep. But once you know it, you
 can very very productive with it, *on any platform*, because it looks the
 same *on all platform*. Looking native might be a nice selling or demo
 thing, but it's just irrelevant (or even counter-productive) for a whole
 class of applications.

 So please, please... keep improving widgets! :-) some things are unnecessary
 difficult to do, some features would be so nice to have...


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about Qt's future

[m...@rpzdesign.com]

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

After reading these:

http://qt-project.org/doc/qt-5/topics-graphics.html
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html#scene-graph-and-rendering

What I think would be a solution is to create a starting point
where Qt Widget 2.0 development could begin anew again based on the
QQuickPaintedItem class.

I think the notion of a Window with child custom controls is not too far
fetched.

My suggestion is basically to provide an early off ramp for QQuickWindow
to allow for 100% C++ projects.

This may even serve as the foundation for custom controls in QML as
well, don't know enough right now to be dangerous.

It would definitely provide current Qt Widget users a sense of ease
that the Widget option is still available even though QtQuickWindow is
the future focus.

QML and QTWidget would then both use the same dual GUI/render thread
foundation, but it would be good to have an early C++ jumping off point
for QQuickWindow based projects.

I do not really care about .ui file support.  For all I can see, 100%
C++ GUI is fine.

What do you think?

Cheers,

md


On 4/21/2014 12:19 PM, Thiago Macieira wrote:
 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, the effort required for this is enormous. It basically requires 
 rewriting all or almost all widgets from scratch so that they work in a 
 retained-mode OpenGL scene graph, instead of imperative-mode raster buffer 
 painting. It's a complete paradigm change.
 
 Since this requires a rewrite, instead of doing it in QtWidgets and risking 
 regressions that users will not accept, the idea was instead to do it in a 
 different module, one where we can experiment and at the same time clean up 
 some of the mistakes that exist in QtWidgets and can't be cleaned up without 
 annoying someone. 
 
 That's the Qt Quick Components.
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about Qt's future

[m...@rpzdesign.com]

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 
oriented toolkit, but I ran Qt Widgets in
test on Qt 5.2.1 IOS/Android and they seemed to work.

What is the design pattern/architecture that QML provides that renders 
Qt Widgets obsolete?

Isn't Qt Widgets so mature that they are stable?

Will Qt Widgets / Qpainter be so inefficient on IOS/Android that only 
using QML with screengraph/opengl
is the available choice.

The case has not been made either for or against QML and their use cases 
not well documented
with respect to the amount of focus on QML and the reasons for that 
design direction.

Look forward to the Monday discussion threads

md

On 4/20/2014 9:40 PM, 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 sure that they will not abandon C++ side of Qt and that they
 continue to develop C++ side.It seems to me that they are developing Qml side
 mostly.

 What do you think about this?

 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Android / IOS

[m...@rpzdesign.com]

Hello Development:

I am newly arrived on Qt 5.2x scene and wanted to know how to contribute 
code, fixes,
and testing for Qt 5.3.x of IOS and Android.

Specifically, I want to focus on QT C++ - Objective C/Cocoa bridge
and QT C++ - Android/Java/JNI.

Is the development email list a free flowing forum or are there 
different subgroups
each with their own list or developer forum somewhere.

Where can I access threads of those focused on Android and IOS 
integration issues?

Thanks for any replies,

Marco
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development