Re: [Development] Qt 5.3 header diff

[Andrey Ponomarenko]

Thiago Macieira wrote:
> Em qua 23 abr 2014, às 16:50:45, Andrey Ponomarenko escreveu:
>> I've created the ABI compatibility report between 5.2.1 and 5.3.0-beta
>> versions:
>> http://upstream-tracker.org/compat_reports/qt/5.2.1_to_5.3.0-beta/abi_compat
>> _report.html
> Thanks Andrey! I'll take a look at the report soon.
>
> Can you be prepared to run the report for rc1 when it's out? It's much closer
> to the release.
>

Yes, sure. I'll write a similar message to the list when rc1 will be 
released.

-- 
Andrey Ponomarenko, NTC IT ROSA.

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

Re: [Development] CI Jenkins will be updated today

[Sarajärvi Tony]

>Hi
>
>We will update Jenkins to hopefully a more stable version. We have tried it 
>already on dev side and the update process went fine.
>
>The update will happen after the current qt5 release integration build, which 
>will occur around noon, i.e. in 3 hours or so.
>

We already began the update process. Have to sort out new errors with Groovy 
scripts that seem to cause builds to fail. 

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

Re: [Development] Question about Qt's future

[Simon Hausmann]

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 speaking for Michael, but let me add that C++ is much easier to
> debug compared to QML, if you get a crash. We have nearly hundred
> backtraces in the Plasma bug tracker that point back to crashes in
> QtDeclarative, without a single clue where the crash comes from. For
> examples see bugs 328234, 332131, 331060, 333621, 333532, 34,
> 332995, or 332646 to cite only some fairly recent ones.
> 
> I am not blaming QML here, all those bugs are possibly caused by
> errors in Plasma itself, but the fact that you cannot see from the
> backtrace what caused the crash is a major concern for me.

Let's turn this from a blame game into something more productive.

The nature of the beast is that we do have two language environments here and 
they do (and can't) share the same stack, so stack traces will always be 
separate. However there are ways of determining the "current" JavaScript stack 
trace in parallel. Note that this isn't possible with Qt 5.1 or older, but 
starting with Qt 5.2 it is possible.

Friedemann was kind enough to lay the infrastructure for that in QtQml and 
used it on the Qt Creator side, in a way that could also be used by KDE's 
drkonqi:

It will require a little bit of analysis and interaction with gdb, but I think 
it's doable. It will require looking at the frames gdb reports, and if you see 
functions that take a QV4::ExecutionContext * as a parameter, then you can 
extract the "address" from the gdb output and then call the qt_v4StackTrace 
function in QtQml from within gdb. It will print out a JavaScript stack trace. 
This works rather well and Qt Creator 3.1 provides it through the context menu 
in the debugger, if you'd like to try it out yourself.

This way bug reports in KDE that somehow involve Qt JavaScript execution can - 
in parallel - include a C++ backtrace and a JS stack trace.


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

Re: [Development] Qt 5.3 header diff

[Sune Vuorela]

On 2014-04-23, Andrey Ponomarenko  wrote:
> I've created the ABI compatibility report between 5.2.1 and 5.3.0-beta 
> versions: 
> http://upstream-tracker.org/compat_reports/qt/5.2.1_to_5.3.0-beta/abi_compat_report.html
>
> Hope it may be helpful to analyse changes in headers.

that abi tool is btw amazing.

Is it the constant changes in bluetooth and pagesize and the changes to 
qopenglfunctionsprivate that gives the verdict:

| Incompatible

/Sune

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

Re: [Development] Qt 5.3 header diff

[Andrey Ponomarenko]

Sune Vuorela wrote:
> On 2014-04-23, Andrey Ponomarenko  wrote:
>> I've created the ABI compatibility report between 5.2.1 and 5.3.0-beta
>> versions:
>> http://upstream-tracker.org/compat_reports/qt/5.2.1_to_5.3.0-beta/abi_compat_report.html
>>
>> Hope it may be helpful to analyse changes in headers.
> that abi tool is btw amazing.
>
> Is it the constant changes in bluetooth and pagesize and the changes to
> qopenglfunctionsprivate that gives the verdict:
>
> | Incompatible

Yes, it is. Changes marked by red colour in the report give incompatible 
verdict. Other changes are low severity warnings. But anyway, all found 
problems (both high- and low-severity ones) should be verified by 
maintainers of the library in order to separate real problems, false 
positives and changes in internal data types.

Thanks.

-- 
Andrey Ponomarenko, NTC IT ROSA.

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

[Development] QtQml value types

[Roland Winklmeier]

Hi list,

we discussed the topic whether non-QObject types can be used in QML or not
several times. The last time is only a few days ago as part of the Qt
future discussions. So I had some thoughts what needs to happen to solve
this issue.

I can remember someone told me there are plans to add such a feature. So my
first question is, how far are we on this? Is it just a plan or is someone
really working on it already? Are there any details?

If there is nothing happening at the moment, I'd like to share some ideas I
had during the last days.
I'm not an expert in QtQuick/QML internals so I have no idea what might be
possible or not. At the moment I assume only QObject derived classes can be
used in QML contexts.

Charley's presentation (
http://www.qtdeveloperdays.com/sites/default/files/presentation_pdf/QtDevDaysSFO-2013_WrappingCppForQml_final.pdf)
was very interesting to me as I see this as a possible workaround until
something more sophisticated is in place.
During discussions in our team one of the members pointed me to internal
class QQmlValueType (
https://qt.gitorious.org/qt/qtdeclarative/source/HEAD:src/qml/qml/qqmlvaluetype_p.h).
This is used to make Qt value types like QSize, QPointF available through a
QObject wrapper and is very similar to what charley presented.
Now I wonder can't we just make this (or something similar) available as a
public API? This would allow developers to add their custom types without
much effort and would solve a lot problems.
I don't think this is much effort but it will help a lot.

Thoughts?

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

Re: [Development] QtQml value types

[Simon Hausmann]

On Thursday 24. April 2014 11.55.07 Roland Winklmeier wrote:
> Hi list,
> 
> we discussed the topic whether non-QObject types can be used in QML or not
> several times. The last time is only a few days ago as part of the Qt
> future discussions. So I had some thoughts what needs to happen to solve
> this issue.

Thank you for taking this out of the "future of Qt" thread (which seemed 
counterproductive). I wanted to do the same today :). I'm interested in 
contributing to the actual implementation of making it easier to use value 
types in QML. I'm aware of attempts from the past and I'm familiar with the 
current internal implementation. However it's not entirely clear to me yet 
what the presumably best way is for making it part of the public API.
 
> I can remember someone told me there are plans to add such a feature. So my
> first question is, how far are we on this? Is it just a plan or is someone
> really working on it already? Are there any details?
 >
> If there is nothing happening at the moment, I'd like to share some ideas I
> had during the last days.
>
> I'm not an expert in QtQuick/QML internals so I have no idea what might be
> possible or not. At the moment I assume only QObject derived classes can be
> used in QML contexts.
> 
> Charley's presentation (
> http://www.qtdeveloperdays.com/sites/default/files/presentation_pdf/QtDevDay
> sSFO-2013_WrappingCppForQml_final.pdf) was very interesting to me as I see
> this as a possible workaround until something more sophisticated is in
> place.
> During discussions in our team one of the members pointed me to internal
> class QQmlValueType (
> https://qt.gitorious.org/qt/qtdeclarative/source/HEAD:src/qml/qml/qqmlvaluet
> ype_p.h). This is used to make Qt value types like QSize, QPointF available
> through a QObject wrapper and is very similar to what charley presented.
> Now I wonder can't we just make this (or something similar) available as a
> public API? This would allow developers to add their custom types without
> much effort and would solve a lot problems.
> I don't think this is much effort but it will help a lot.

QQmlValueType is quite good in what it does. It could be that this is what we 
should be doing.

On the other hand for QtScript Kent came up with a solution that's strikingly 
beautiful at first:

scriptEngine->setDefaultPrototype(qMetaTypeId(), prototype);

It means that whenever a value type with the given meta-type ID enters the 
JavaScript world, the object that's being created to wrap the value will have 
the given object as prototype set.

That's incredibly powerful if you think about it, it even allows implementing 
functionality for value types in JavaScript itself.

Now the usability of this API depends on the availability of C-style function 
callbacks in QJSEngine in order to effectively allow wrapping in C++. That 
itself is something we've been hesitant about due to the way this exposes 
internals of the engine.

At the same time - even if we had C callbacks - we have to ask ourselves: 
What's the right data representation? For each operation, would we have to 
unpack a QVariant out of a QJSValue and then cast it to whatever the specific 
value type is?

Theoretically this is something that QQmlValueType solves, but in practice if 
you have for example a QPoint and code like this:

var p = someObject.position;
p.x = 42;
p.y = 100;

Then the load and store from say variant is executed twice each.


It gets more complex when you consider that value types are semantically 
different in JavaScript. In the above example modifying p.x actually modifies 
someObject.position.x, i.e. someObject will probably move on the screen.


These are just some initial thoughts - there are many things to consider. It's 
one of the topics we should try to discuss at the Qt contributor summit. But 
perhaps until then we can come up with an intermediate initial solution here 
on the mailing list - flexible enough to allow for extension in the future.

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

Re: [Development] Question about Qt's future

[André Pönitz]

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 language environments here
> and they do (and can't) share the same stack, so stack traces will always
> be separate.

There are two separate issues here: 1. The requirement to have two sources
of stack frames, and 2. the specific setup of the JS stack extraction
machinery.

Re 1: It is possible to get a single unified stack trace using standard
tools an application that's wildly mixing languages (in case of GDB e.g.
C++, C, Fortran, ADA, D, Modula 2 and a few others) _on the same stack_
_out of the box_. Such a single frame source is ideal from a tooling
perspective as it allows complete re-use of standard debugging and
profiling tools, as well as free integration into platform native IDEs
like Visual Studio or Xcode.

We could get there, but that would require de-emphasizing the importance
of JavaScript in the QML/JS conglomerate, i.e. primarily targeting a
"Pure-Declarative-UI plus C++-Core scenario". I understand that you don't
want that, but being able to re-use standard tools is the only feasible
long-term approach.

Re 2: The two sources of stack frames can be worked with in
certain setups: There are examples to e.g. extract data
from a mixed C++/Python setup using GDB (quick search finds
https://fedoraproject.org/wiki/Features/EasierPythonDebugging, but I
think I saw something more complete once). Some problems remain:
- "Certain setups": To make that work cross-platform such an integration
  would be needed for all widely used native debugging backends
  (currently GDB, CDB, LLDB) i.e. at least tripled work for us - and
  that's already assuming the CDB calling restrictions don't interfere,
  i.e. it is possible at all)
- The stack interweaving requires active IDE support, or at least some
  layer on top of two language-specific frame extraction machineries.
  We can do that with some effort for Qt Creator. There might be
  some kind people repeating that work for KDevelop, and possibly some
  others, at some time. VS? Unlikely. Xcode? No chance.
[- At least at V8 times (I really haven't looked at V4 yet, I understand
  it should be less of an issue there), JS stack extraction required the
  JS engine to "run", while the C++ side needed to be "stopped" to get
  their respective frames. This requires extra co-ordination on the IDE
  side and rules out debugging scenarios like "post mortem"/"core files"
  which are rather common for non-trivial applications.]
- Repeat for profiling. And any other kind of project analysis.

All in all, the cases where "mixed stacks" really work well are very
limited and even those cases come with a steep price tag. Which brings me
back to #1: The only reasonable, long-term feasible approach is one that
allows the direct re-use of standard tools.

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

Re: [Development] QtQml value types

[Joshua Kolden]

I’m sorry I intended to respond to this in the other thread, but super busy.  
Nevertheless I think it’s important for people to know there are answers to 
this now without waiting for any new APIs so I stole the time to write our 
process out.

We have a solution that works very well for us using QVariantMaps and an MVC 
pattern / strong separation between data objects and view.  It appears to me 
that most people are having this issue because it’s not common to use MVC with 
QtWidgets.  But you can easily expose complex data structures to QtQuick 
without subclassing QObject via QVariantMaps. 

On the data side your `value classes` are best when optimized for the domain 
you use them in.  You rightly don’t want to contaminate them with view logic.  
Conversely you don’t want to contaminate your view with specific knowledge of 
internal data representations.  This is where the controller comes in to map 
the view concepts to the model data allowing either to change independently of 
each other.

Things like 
`dataModel->getAircraft().getCom1().getFrequency(chosenUnit).toQString();` are 
generally bad practice in OO design regardless of QML or Qt because it’s 
fragile, and requires knowledge of every step in the chain.  If however you can 
provide an interface that just returns frequencies say, then do whatever you 
want with your value classes behind that interface without worrying that it’ll 
break your UI.

We do this by creating controllers based on UI concepts. For us these include: 
“groups”, “assets”, “processes”, “accounts” etc.  For you it might be things 
like “communications”, “navigation”, “flight_controls”, “simulator_state”, or 
whatever works best for you conceptually.  We create QObject based controllers 
on the C++ side for each of these conceptual areas, and expose a select few 
signals as the interface to pass data back and forth to the view. We do this 
for widget apps, and web apps too, it’s not a workflow that is specific to QML.

It works a lot better than having a separate QObject for every value class 
since it lets you keep your data models focused on the problems they are 
designed to solve without regard to the display of the data.  Conversely in the 
GUI we just have the data we need we don’t need to care about how it is derived.

In QML QVariantMaps show up as javascript object/hashes/maps (whatever you like 
to call them).  They can have arbitrary nesting, and data types, so you can 
maintain or alter your data representation at your desecration.  The data can 
than be mapped to QML object properties in a declarative way, either once for 
the entire data representation or individually for each attribute.

 (With QML a better mental model might be ‘link’ to data as apposed to passing 
data ‘back and forth’ since we don’t do a lot of method calling. Properties 
work automatically via signals, so it’s a bit more like a patch panel, once the 
connections are made they just work moving the data back and forth as it 
changes on either side.)  

For example:

Rectangle {
 id: radioInterface
 property var comData: communications.com
function foo() {
frequencyDisplay.text = comData.com1.frequency;
...
}

or

Rectangle {
 id: radio Interface
 property var com1freq: communications.com.com1.frequency
 property var com1amp: communications.com.com2.amplitude
…
}

For the controller you’d have something like this:

class CommunicationsController : public QObject
{
Q_OBJECT
Q_PROPERTY(QVariantMap com READ com WRITE setCom NOTIFY comChanged)
…
public:
 
QVariantMap com() const;

public slots:

  void setCom(const QVariantMap& com);

signals:

  void comChanged();
}

Later you expose this controller to QtQuick with something like.

CommunicationsController communications;
interface.addProperty(“communications", &communications);

Now everything is connected.  On the QML side you can just directly access the 
values as above, or copy them to a javascript object (i.e. `var comData = 
communications.com`) etc.  On the c++ side you can set and read values in this 
structure with the QVarianMap accessors.

QVariantMap comData;
QVariantMap com1;
com1[“frequency”] = 
dataModel->getAircraft().getCom1().getFrequency(chosenUnit).toQString(); // if 
you must
comData[“com1”] = com1;
return comData;

and

dataModel->getAircraft().getCom1().setFrequency(com[“com1][“frequency”].toFloat());
 // or whatever type

The only thing that’s a consideration with QVariantMaps vs QObjects is that you 
can’t include methods.  But that’s where the OO design comes in which tells us 
we shouldn’t have too many operations happening on data in the views anyway.  
Nevertheless if you truly need to have operators such as convince helper 
methods in the view you can expose them with Q_INVOKABLE methods in the 
controller.

It’s important to note that this workflow is in production now with our 
software and works great, and is very maintainable.  The javascript data models 
are very easy 

Re: [Development] Styling Qt Quick Items

[Bache-Wiig Jens]

On 24 Apr 2014, at 00:57, Alex Montgomery 
mailto:apmontgom...@gmail.com>> wrote:

Hello,

While trying to style a ComboBox such that its text didn't elide and it didn't 
have inexplicably large margins, I was surprised to learn that these two items 
would be displayed entirely differently:

ComboBox { model: ["1", "2"] }
ComboBox { model: ["1", "2"]; style: ComboBoxStyle{} }

Which leads me to these questions:
- Is there a reason that a default constructed ComboBoxStyle (and other Qt 
Quick style types) is not identical to the style of default constructed 
ComboBox?

When you style the control you basically take complete control of it’s looks. 
It is extremely hard to maintain partial fallbacks to native looks when some 
things are touched and others are not and the visual result tend to depend on 
the platform you run it on.

To get an idea, the only thing that is vaguely supported and working well this 
way in widget style sheets is setting the text foreground colour. Pretty much 
anything else will force the style sheet to draw the widget as a Windows 95 
control as a common fallback on all platforms. Most native styles draw controls 
using pixmaps and cannot be tweaked and modified in any useful way without 
completely replacing the original styling.

When you actually do a custom theme, it is more reliable to have a consistent 
appearance path on all platforms which is what the base style does. I think the 
real issue here is why the native control is not eliding in the first place, so 
fixing that would be the preferred solution. This is probably QStyle/platform 
specific and should be filed as a separate issue.

- Is there a way for someone to define their own style that subtly tweaks the 
default style without digging through Qt source code to find the actual default 
properties?
I think the style classes would be far more useful if users could define 
individual properties that they wanted to change without having to specify 
every other property to match the (undocumented) properties set by the ComboBox 
constructor.

I think the idea of tweaking existing native styles without replacing them 
would be better solved by applying an object containing style hints that can be 
respected or not depending on the platform you run on. That way I imagine you 
would be able to set properties like “text-color”, “background” or 
“border-type" property and allow the style to respect it if and only if it is 
actually supported. We have a plan on supporting this through the “stylehints: 
property but we have currently not yet determined exactly how inheritance or 
selectors should be applied.

Regards,
Jens

Regards,
Alex
___
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] Question about Qt's future

[Simon Hausmann]

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 the past.
> 
> > The nature of the beast is that we do have two language environments here
> > and they do (and can't) share the same stack, so stack traces will always
> > be separate.
> 
> There are two separate issues here: 1. The requirement to have two sources
> of stack frames, and 2. the specific setup of the JS stack extraction
> machinery.
> 
> Re 1: It is possible to get a single unified stack trace using standard
> tools an application that's wildly mixing languages (in case of GDB e.g.
> C++, C, Fortran, ADA, D, Modula 2 and a few others) _on the same stack_
> _out of the box_. Such a single frame source is ideal from a tooling
> perspective as it allows complete re-use of standard debugging and
> profiling tools, as well as free integration into platform native IDEs
> like Visual Studio or Xcode.
> 
> We could get there, but that would require de-emphasizing the importance
> of JavaScript in the QML/JS conglomerate, i.e. primarily targeting a
> "Pure-Declarative-UI plus C++-Core scenario". I understand that you don't
> want that, but being able to re-use standard tools is the only feasible
> long-term approach.

Ah, is this based on the idea that the .qml files would not contain any code 
but merely describe the UI layout, and all the logic is entirely and 
exclusively implemented in C++ or any other language supported by the same 
compilation and run-time environment? (i.e. eliminate JavaScript from Qml)


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

Re: [Development] Documenting JavaScript with QDoc

[Milian Wolff]

On Tuesday 22 April 2014 11:00:09 Reinio Topi wrote:
> > Hello!
> > 
> > I'm trying to add documentation to the JavaScript API of QWebChannel. It
> > is a fundamental part of this module and as such, I think proper
> > documentation is crucial.
> > 
> > So far, I have not found a way to get qdoc to generate a page for my .js
> > file for me. Can it? Or do I have to create a separate .qdoc file, and -
> > if so - what commands to I need to use in that file?
> 
> qdoc can parse .js files, however the terminology it uses in the html output
> is more geared towards QML type documentation. That said, you can see how
> it looks like - by default, .js files are not parsed for documentation
> comments, but you can enable it by adding a line
> 
> sources.fileextensions += "*.js"
> 
> into your .qdocconf. No need to use separate .qdoc files or dummy .cpp
> files.

Hm, I tried this but the next issue that I have a C++ "QWebChannel" class and 
a JavaScript QWebChannel. Thus I get:

warning: "QtWebChannel" Cannot locate index file for dependency "qtwebsockets"
/ssd/milian/projects/qt5/qwebchannel/src/webchannel/qwebchannel.js:57: 
warning: Overrides a previous doc
/ssd/milian/projects/qt5/qwebchannel/src/webchannel/qwebchannel.cpp:53: 
warning: (The previous doc is here)

Is QDoc even able to understand that the following is considered a class 
(following the constructor function pattern)?

var foo = function()
{
  ...
};
 
> Also, although not strictly required, any \qmltype should belong to a
> \qmlmodule. Even though this is abusing the qdoc commands a bit, you
> could try something like:
> 
> /*!
> \qmlmodule qwebchannel.js
> \title Qt WebChannel JavaScript API
> */
> 
> /*!
> \qmltype foo
> \inqmlmodule qwebchannel.js
> */

Yes, this brings me a bit further than before. But the output is far too QML 
specific. It e.g. lists an "Import Statement: import qwebchannel.js" which is 
of course not what I want for a JavaScript file which should be included in 
HTML clients...

So I think I'll stick to the \page approach and just document everything in 
textual form there. Not nice, but better than the alternatives, apparently.

Thanks for the help Reinio!

> > I tried something like this:
> > 
> > /*!
> > 
> > \title Qt WebChannel JavaScript API
> > \page javascript.html
> > 
> > To communicate with a QWebChannel or WebChannel, any HTML client must
> > use
> > 
> > and setup the
> > 
> > JavaScript API provided by \c qwebchannel.js.
> > 
> > */
> > 
> > /*!
> > 
> >  \qmltype foo
> >  
> >   asdfsadf
> > 
> > */
> > 
> > /*!
> > 
> >  \qmlmethod bool foo::test();
> >  
> >   foo bar
> > 
> > */
> > 
> > On the javascript.html page, I then cannot see anything about foo nor
> > foo::test... Is there maybe a module out there which documents "pure" .js
> > files? In QtDeclarative, I only found documentation for  .cpp/.qml
> > functions so far. Even things like qsTr are actually documentation for a
> > .cpp method which gets renamed using \qmlmethod...
> > 
> > Hope anyone can help me here. The only potential workaround I could think
> > of so far would be adding a dummy .cpp file for the documentation of the
> > .js API of the QWebChannel.
> > 
> > Thanks
> > 
> > 
> > Milian Wolff | milian.wo...@kdab.com | Software Engineer
> > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> > Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
> > KDAB - Qt Experts - Platform-independent software solutions
> 
> ___
> 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

-- 
Milian Wolff
m...@milianw.de
http://milianw.de
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changelogs for 5.3.0

[Thiago Macieira]

Em qua 23 abr 2014, às 21:22:40, Alan Alpert escreveu:
> On Tue, Apr 22, 2014 at 3:13 PM, Thiago Macieira
> 
>  wrote:
> > Please find attached the raw logs for each of the modules that had any
> > [ChangeLog] in the v5.2.1..origin/release range.
> > 
> > I'm taking responsibility of editing the one for qtbase.
> > 
> > For all other modules, I'd like someone to reply to this email saying
> > they'll be the editor. Otherwise, there will be no changelog for the
> > module at all, because I won't do it.
> 
> I'll edit qtquick1. First draft at
> https://codereview.qt-project.org/#change,83982 (and it's just one
> item... probably ready to go).
> 
> Also qtdeclarative, which I didn't see in the attachments, but running
> the script and adding the output to the existing changelog gives
> another 'first' draft: https://codereview.qt-project.org/#change,83983

Comments there.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Changelogs for 5.3.0

[Bache-Wiig Jens]

I edited and updated the controls related change log here:

https://codereview.qt-project.org/#change,84066

On a somewhat related note, I would suggest that for future updates we
standardize on putting the bug-id after each item entry rather than in front
as that would make the document a bit more readable in my opinion.
I don’t really see any valid reason why people would remember a specific
task number and scan that list manually.

Jens

On 24 Apr 2014, at 06:57, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

Em qua 23 abr 2014, às 21:22:40, Alan Alpert escreveu:
On Tue, Apr 22, 2014 at 3:13 PM, Thiago Macieira

mailto:thiago.macie...@intel.com>> wrote:
Please find attached the raw logs for each of the modules that had any
[ChangeLog] in the v5.2.1..origin/release range.

I'm taking responsibility of editing the one for qtbase.

For all other modules, I'd like someone to reply to this email saying
they'll be the editor. Otherwise, there will be no changelog for the
module at all, because I won't do it.

I'll edit qtquick1. First draft at
https://codereview.qt-project.org/#change,83982 (and it's just one
item... probably ready to go).

Also qtdeclarative, which I didn't see in the attachments, but running
the script and adding the output to the existing changelog gives
another 'first' draft: https://codereview.qt-project.org/#change,83983

Comments there.
--
Thiago Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel Open Source Technology Center

___
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] Question about Qt's future

[Attila Csipa]

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 suitable - at least for now.
>
> So our effort goes into making QML suitable.

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 used 
to be cool. It's still VERY good for embedded and custom UIs requiring 
that pixel perfect snappy UI (also the reason why it fares so well in 
the consultancy/solutions business). But. Unfortunately platforms have 
diversified, UIs look/act more different than ever (and it's not going 
to change). This is, indirectly, IMO the reason why Qt Quick Components 
took so long, why they (pardon my French) suck, and why they will suck 
in the foreseeable future, and why I think Qt is (still) so far behind 
in mobile. It seems nobody has the bandwidth to reimplement ALL the 
controls/look'n'feel for ALL the platforms, so they would feel native 
and integrate with the Qt apps seamlessly. This would be OK if Qt was a 
game engine or not trying to have a general application framework 
appeal. The current mobile examples demonstrate IMHO this quite clearly 
- they do have a "I want this" appeal on a first run, but when you 
scratch the surface you see these are more like Potemkin villages than 
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 better - but also worse than other cross 
platform solutions).

Best regards,
Attila

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

Re: [Development] Debugging crashes in QML / QtDeclarative [was: Question about Qt's future]

[Christoph Feck]

On Tuesday 22 April 2014 23:11:59 Kleint Friedemann wrote:
> Hi Christoph,
> 
> > Christoph Feck wrote: Not speaking for Michael, but let me add
> > that C++ is much easier to debug compared to QML, if you get a
> > crash. We have nearly hundred backtraces in the Plasma bug
> > tracker that point back to crashes in QtDeclarative, without a
> > single clue where the crash comes from. For examples see bugs
> > 328234, 332131, 331060, 333621, 333532, 34, 332995, or
> > 332646 to cite only some fairly recent ones.
> 
> Please take a look at
> https://bugreports.qt-project.org/browse/QTCREATORBUG-11144 and
> the related changes in Qt Creator 3.1 . When doing pure C++
> debugging, Qt Creator now has a context menu entry "Load QML
> frames" in the stack window. This basically checks the stack trace
> for a value of a  QV4::ExecutionContext *, tries to extract the
> JavaScript stack frames from it and displays those frames in
> addition to the C++ frames.

I wasn't aware it's actually possible to get QML backtraces. I filed 
an enhancement request for KDE's crash handler DrKonqi as KDE bug 
333816, citing your and Simon's reply.

Thanks!

-- 
Christoph Feck
http://kdepepo.wordpress.com/
KDE Quality Team
openSUSE Review Team
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changelogs for 5.3.0

[Thiago Macieira]

Em qui 24 abr 2014, às 16:25:41, Bache-Wiig Jens escreveu:
> On a somewhat related note, I would suggest that for future updates we
> standardize on putting the bug-id after each item entry rather than in front
> as that would make the document a bit more readable in my opinion. I don’t
> really see any valid reason why people would remember a specific task
> number and scan that list manually.
> 
> Jens

Sounds good. You can submit an update to the create_changelog.pl script 
(qtsdk/packaging-tools), it should be fairly simple. I'll do it later if you 
don't though.

PS: it would be nice if the changes to the changelog script got approved by 
someone...
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] QtQml value types

[Dominik Holland]

Am 24.04.14 12:46, schrieb Simon Hausmann:
> On Thursday 24. April 2014 11.55.07 Roland Winklmeier wrote:
>> Hi list,
>>
>> we discussed the topic whether non-QObject types can be used in QML or not
>> several times. The last time is only a few days ago as part of the Qt
>> future discussions. So I had some thoughts what needs to happen to solve
>> this issue.
> Thank you for taking this out of the "future of Qt" thread (which seemed
> counterproductive). I wanted to do the same today :). I'm interested in
> contributing to the actual implementation of making it easier to use value
> types in QML. I'm aware of attempts from the past and I'm familiar with the
> current internal implementation. However it's not entirely clear to me yet
> what the presumably best way is for making it part of the public API.
>   
>> I can remember someone told me there are plans to add such a feature. So my
>> first question is, how far are we on this? Is it just a plan or is someone
>> really working on it already? Are there any details?
>   >
>> If there is nothing happening at the moment, I'd like to share some ideas I
>> had during the last days.
>>
>> I'm not an expert in QtQuick/QML internals so I have no idea what might be
>> possible or not. At the moment I assume only QObject derived classes can be
>> used in QML contexts.
>>
>> Charley's presentation (
>> http://www.qtdeveloperdays.com/sites/default/files/presentation_pdf/QtDevDay
>> sSFO-2013_WrappingCppForQml_final.pdf) was very interesting to me as I see
>> this as a possible workaround until something more sophisticated is in
>> place.
>> During discussions in our team one of the members pointed me to internal
>> class QQmlValueType (
>> https://qt.gitorious.org/qt/qtdeclarative/source/HEAD:src/qml/qml/qqmlvaluet
>> ype_p.h). This is used to make Qt value types like QSize, QPointF available
>> through a QObject wrapper and is very similar to what charley presented.
>> Now I wonder can't we just make this (or something similar) available as a
>> public API? This would allow developers to add their custom types without
>> much effort and would solve a lot problems.
>> I don't think this is much effort but it will help a lot.
> QQmlValueType is quite good in what it does. It could be that this is what we
> should be doing.
>
> On the other hand for QtScript Kent came up with a solution that's strikingly
> beautiful at first:
>
>  scriptEngine->setDefaultPrototype(qMetaTypeId(), prototype);

I like that idea, but couldn't we do something like this ?

qRegisterWrapper(qMetaTypeId())

MyWrapper is a QObject based class which can whatever you want and gets 
YourType as reference or per value.

It would mean you create your wrapper once for all your Types of your 
Interface and afterwards the QmlEngine will create the Wrapper 
automatically for every object which is exposed to QML.

I could also think of having some automatically created wrappers for 
QList.


The wrapper itself gives you the flexiblity to decide whether you can 
support changedSignals of what functions you want to expose to QML.

In the end it would also be great to register the Wrapper as a own QML 
Type to be able to create the object in QML.

Dominik

> It means that whenever a value type with the given meta-type ID enters the
> JavaScript world, the object that's being created to wrap the value will have
> the given object as prototype set.
>
> That's incredibly powerful if you think about it, it even allows implementing
> functionality for value types in JavaScript itself.
>
> Now the usability of this API depends on the availability of C-style function
> callbacks in QJSEngine in order to effectively allow wrapping in C++. That
> itself is something we've been hesitant about due to the way this exposes
> internals of the engine.
>
> At the same time - even if we had C callbacks - we have to ask ourselves:
> What's the right data representation? For each operation, would we have to
> unpack a QVariant out of a QJSValue and then cast it to whatever the specific
> value type is?
>
> Theoretically this is something that QQmlValueType solves, but in practice if
> you have for example a QPoint and code like this:
>
>  var p = someObject.position;
>  p.x = 42;
>  p.y = 100;
>
> Then the load and store from say variant is executed twice each.
>
>
> It gets more complex when you consider that value types are semantically
> different in JavaScript. In the above example modifying p.x actually modifies
> someObject.position.x, i.e. someObject will probably move on the screen.
>
>
> These are just some initial thoughts - there are many things to consider. It's
> one of the topics we should try to discuss at the Qt contributor summit. But
> perhaps until then we can come up with an intermediate initial solution here
> on the mailing list - flexible enough to allow for extension in the future.
>
> Simon
> ___
> Development mailing list
> Development@qt

Re: [Development] Question about Qt's future

[Sze Howe Koh]

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 QML is used in multimedia, position modules
> and so on ...

Yes, that's true. I think WebKit 2 and 3D audio are the odd ones out
though (I'm not sure why they did this -- we'll have to ask the devs).
Nokia invented QML for the purpose of GUI development, but I guess
people find it convenient to be able to access non-graphical features
directly from QML.

Except for graphics, WebKit 2 and 3D audio, all other QML features
(including other multimedia features and Qt Positioning) are simply a
QML counterpart to C++ features.


> It's absolute clear that if you want to manually edit the UI file, there's
> no point to compare the solutions, QML is preferred instead of writing xml
> mannually.
> But what I meant is to create the UI file with some specific UI editor like
> QtDesigner or Android UI editor. You don't have to write the file manually.

Have you seen Qt Quick Designer?
http://qt-project.org/doc/qtcreator-3.1/creator-using-qt-quick-designer.html
It doesn't matter whether your file is .ui or .qml -- you can use a
visual editor and you don't need to modify the files directly to
create your UI. (Of course, you'd still need to implement slots and
signal handlers in C++ and QML respectively)


> So what I don't understand why Android xml file can be the most efficient
> way to define the UI for that platform for many developers, and why we are
> somehow forced to abandon QtDesigner UI (xml) files in favor of QML.

To understand this, you need to look at Qt's history. Here is a simple
timeline of Qt UI technologies:

1995 -- (C++) -- Widgets introduced
2006 -- (C++) -- Graphics View Framework introduced
2010 -- (QML) -- Qt Quick 1 introduced, built on the Graphics View Framework.
2012 -- (QML) -- Qt Quick 2 introduced, built on a new OpenGL framework.

The Graphics View Framework supports UI technologies which are
important to many modern platforms, such as animated transitions.
Widgets don't support these techs easily (you need to write lots of
code to make it work).

Android was released in 2008 and Android XML files were designed for
modern UI techs. In contrast, Qt's .ui XML files can only assemble
Widget-based GUIs. To compete with Android GUIs, you often need to use
Graphics View, which makes the .ui XML files less useful -- you need
to define your UI layout in C++ code, which is inefficient. QML and Qt
Quick and Qt Quick 1 aimed to make it easier to write GUIs for the
Graphics View Framework.

Qt Quick 2 provides superior performance than Qt Quick 1. It can do
everything that Graphics View and Qt Quick 1 can do, so it replaces
these technologies. However, it can't do everything that Widgets can
do yet, so it doesn't replace Widgets yet. Nobody needs to abandon Qt
Designer. New features are still being added to Qt Widgets (see
http://qt-project.org/wiki/New-Features-in-Qt-5.2), and it will still
be supported for many years. I still use it to create traditional
office-style GUIs.

However, when I want to make modern fluid GUIs, I use Qt Quick,
because it is much more efficient for this purpose compared to Qt
Widgets.


On the topic of efficiency and animations, compare these 2 examples
which do similar things:
* http://developer.android.com/training/animation/cardflip.html
* http://qt-project.org/doc/qt-5/qml-qtquick-flipable.html

Files required:
- Android: 6 XML files + 1 Java file
- Qt Quick: 1 QML file

Code required (excludes XML/comments/braces/empty lines)
- Android: 34 lines of Java code
- Qt Quick: 23 lines of QML code
- (Also note: the average QML line is shorter than the average Java line)

I think QML is for more efficient than Android's XML+Java to create a
card flip effect.

Finally, here is a Graphics View card-flipping example, which is also
far less efficient than the QML example:
https://blog.qt.digia.com/blog/2009/06/09/flippin-widgets-medium-rare-please/


Again, the bottom line is:
* Choose the best tool currently available for the job.
* Choose Qt Quick and QML for mobile phone apps.
* Choose Qt Widgets and .ui XML files for traditional desktop office-style apps.


Does this answer your question?


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

Re: [Development] Question about Qt's future

[Sze Howe Koh]

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 highlighting the fact that their declarative
structures make QML or HTML+CSS good for describing a GUI's looks.
This is in contrast to imperative languages like C++ or JavaScript or
PHP -- I don't want to use any of these to describe a GUI's looks.

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.
(Alternatively, one could argue that QML is a hybrid
declarative-imperative language).


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

Re: [Development] Question about Qt's future

[Sze Howe Koh]

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 2 and 3D audio are the odd ones out
> though (I'm not sure why they did this -- we'll have to ask the devs).
> Nokia invented QML for the purpose of GUI development, but I guess
> people find it convenient to be able to access non-graphical features
> directly from QML.
>
> Except for graphics, WebKit 2 and 3D audio, all other QML features
> (including other multimedia features and Qt Positioning) are simply a
> QML counterpart to C++ features.

I forgot: Qt WebKit is being deprecated in favour of the
Chromium-based Qt WebEngine. Qt WebEngine will have both Widget and
QML APIs.[1]


Regards,
Sze-Howe

[1] 
http://blog.qt.digia.com/blog/2014/01/23/qt-webengine-technology-preview-available/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QDoc error tracking tool

[Sze Howe Koh]

Hi all,

I've been tracking QDoc errors in an Excel spreadsheet. It takes some
manual labour to convert the QDoc output into spreadsheet form, and
copy my existing notes into a new build.

So, in true hacker spirit, I made a tool to automate all that for me.
I've polished the code and published it at
https://github.com/JKSH/QDocErrorTracker -- I hope it's useful to
others, especially the doc team.

Features:
- Parses the STDERR output of the QDoc build process, to capture issues in the
  documentation source code. Captured issues are stored on disk.
- Displays captured issues in a spreadsheet. Spreadsheet is sortable by
  source repository, file path, error message, etc.
- Easy diff between any two builds.
- Captured issues can be annotated. Annotations automatically apply to all
  builds which contain this particular issue.


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

[Development] ★ Development, Cristian Pallarés te ha dejado un mensaje

[Cristian Pallarés]

Cristian Pallarés  te ha dejado un mensaje

Este mensaje es personal. Solo tú y su remitente tenéis acceso a él y te 
recordamos que lo puedes eliminar en cualquier momento. Si quieres responder 
puedes hacerlo desde el chat. Para leer tu mensaje, haz clic en el siguiente 
enlace:
http://eu1.badoo.com/0347642994/in/Occ99EQXpf8/?lang_id=7&g=57-0-4&m=21&mid=5359f99a0007004d036a669a0150d78e001a


Si al hacer clic en el enlace de este mensaje no funciona, copia y pégalo en la 
barra de tu navegador.


Este email es parte del proceso de entrega del mensaje enviado por Cristian 
Pallarés. Si has recibido este email por error, por favor ignóralo. En un breve 
periodo de tiempo será eliminado del sistema.


¡Divértete!
El Equipo de Badoo

Has recibido este email de Badoo Trading Limited (dirección postal a 
continuación). 
Si no desea recibir futuras comunicaciones por parte de Badoo, haz clic aquí 
para desactivarlas:
https://eu1.badoo.com/impersonation.phtml?lang_id=7&email=development%40qt-project.org&block_code=d98908&m=21&mid=5359f99a0007004d036a669a0150d78e001a&g=0-0-4.

Badoo Trading Limited es una sociedad de responsabilidad limitada registrada en 
Inglaterra y Gales con número 7540255 y domicilio en Media Village, 131 - 151 
Great Titchfield Street, Londres, W1W 5BB.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development