Re: [Development] Multiple QML engines with different import paths, file selectors, etc

[Andreas Aardal Hanssen]

Hi, I don’t necessarily want to walk into the specifics of that feature of this 
change - more that I think compatibility is something that should be considered 
very valuable - to the point that prior to starting work on refactorings that 
break compatibility (in behavior in this case), there should be an option on 
the table to opt in or out of the new behavior. Otherwise, you are pushing the 
problem onto the users. The bigger the user’s codebase, the higher the chance 
that the changes will have unwanted impact. I feel qtdeclarative is 
particularly exposed to compatibility breakage-as-a-default… I wish it was the 
exception rather than the rule.

For this particular issue, I do think unittests that use QQmlEngine with 
different import paths are very common and useful. And you can’t make any 
assumptions about static networkaccessmanager or URL interceptors IMO.

The number of replies to threads in this mailing list also suggests that the 
quality of empiric data is kind of low, so I’m not sure how to conclude if, 
fex, nobody can share use cases… 

Andreas

Tir 9 jan 2024 kl. 10:49 skrev Ulf Hermann via Development:
> So, to clarify this some more ... If:
> 
> 1. you use _multiple_ QML engines in the same process at the same time, 
> 2. you have _different_ import paths, plugin paths, URL interceptors or 
> network access managers for those engines,
> 3. you rely on those engines to produce _different results_ for the 
> _same QML documents_ as a consequence,
> 4. this actually _works_,
> 
> please let me know more about your use case!
> 
> Using multiple engines A, B, ... sequentially where you only start 
> accessing the type registry from engine B after engine A has been 
> destructed does not count since engine A will clean up after itself.
> 
> From my point of view, looking at the source code, such a scenario is 
> rather unlikely since the global type registry should get in your way. 
> However, if it exists, I will consider it in my refactoring.
> 
> best,
> Ulf
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Multiple QML engines with different import paths, file selectors, etc

[Andreas Aardal Hanssen]

Hi, have you considered how you can keep compatibility, by making this change 
either opt-in or opt-out? Since it seems the refactoring is already done, it 
feels like you are making a bet that only has a negative outcome for those 
porting/trying to keep up.  Good for maintenance, bad for users?

Andreas - in favor of Qt keeping its compatibility promises

Man 8 jan 2024 kl. 15:01 skrev Ulf Hermann via Development:
> Hi,
> 
> I'm currently refactoring our QML compilation units to avoid storing 
> engine-specific data in the global type registry since that is dangerous 
> and bug-prone. See e.g. QTBUG-120189.
> 
> This effectively means that you will be able to re-use compilation units 
> between different QML engines. On the surface that is great because your 
> QML engines won't re-compile the same code over and over. However, there 
> are certain attributes to QML engines that can make them produce 
> different QML components from the same code:
> 
> 1. Import paths. You might store different modules with the same URI in 
> different import paths and make them available selectively to only 
> select engines in your process.
> 
> 2. File selectors (or more generally URL interceptors). You can re-write 
> URLs any way you like and you can assign different interceptors to 
> different engines.
> 
> 3. Network access managers. You can implement the same URL scheme in 
> different ways between different engines.
> 
> Different import paths can be useful in reality for versioning of QML 
> modules, but you should certainly not use different versions of the same 
> module within the same process. Using different file selectors or 
> different network access managers between QML engines running in the 
> same process sounds rather obscure to me.
> 
> Now when I'm done with the refactoring, if you do such things, one of 
> your engines may dig up components compiled by one of the other engines 
> with the other engine's settings. That's bad. However:
> 
> 1. I believe the use cases for this are rather few and far between. 
> Please correct me if I'm wrong.
> 
> 2. Since we already have a type registry that currently stores fully 
> engine-specific compilation units, I'm sure there are plenty of bugs in 
> this area that already do turn up the wrong compilation units if used in 
> such a way.
> 
> 3. Different components will also produce different property caches and 
> ultimately different metaobjects. Those are fundamentally global already 
> and should give you plenty of problems if you're doing this.
> 
> In conclusion, I will go ahead with the changes. In addition, I will 
> probably add static versions of those settings (import paths, URL 
> interceptors, network access managers) and deprecate the engine-specific 
> settings, so that you can't accidentally mess this up either.
> 
> best,
> Ulf
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Future of java-style iterators?

[Andreas Aardal Hanssen]

How about QDir::iterator, QDir::cbegin, basically make QDir a container? Or 
make a new class that serves the same purpose… /me likes the QDir idea.. :-)

Andreas

Tir 5 des 2023 kl. 22:15 skrev Mathias Hasselmann via Development:
> Hi,
> 
> would QDirIterator[1] be part of this deprecation? Its API clearly seems 
> be inspired by the Java-style iterators.
> 
> While I do not care much about the other Java-style iterators, I really 
> like this iterator and use it a lot.
> What would be this iterator's modern replacement in Qt?
> 
> Ciao
> Mathias
> 
> [1] https://doc.qt.io/qt-6/qdiriterator.html
> 
> Am 03.12.2023 um 21:56 schrieb Christian Ehrlicher:
> > Hi,
> >
> > Some days ago we got an error report in the forum about QHashIterator,
> > turned out to be a missing documentation for a complete class which
> > remained unnoticed since Qt 6.0
> > (https://bugreports.qt.io/browse/QTBUG-119461).
> > This leads to the question if we should deprecate all java-style
> > iterators since they seem to be a) not widely used and b) it looks like
> > we don't support them in a way we should.
> > What do you think?
> >
> >
> > Cheers,
> > Christian
> >
> >
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] qsizetype

[Andreas Aardal Hanssen]

On Wed, Sep 7, 2022, at 08:45, Kevin Kofler via Development wrote:
> Alex Blasche wrote:
> > 2.) An alternative might be to make this change in one go for Qt 7. We
> > would keep Qt 6.x on the status quo but start adding compatible
> > replacement APi with an absolute change at 7.0 (ifdefs or typedefs come to
> > mind). Users would only be burdened one time (though it being one BIG time
> > effort). Such a change would be much simpler in Qt headers.
> It scares me that a Qt 7 is already being planned or discussed at all, 
> considering that your major consumers such as KDE Plasma are not even ported 
> to Qt 6 yet! (Note that I am talking about *consumers* here, not only about 
> (paying) customers. The former includes FOSS projects such as KDE.)
> Those major/BIC releases need to happen a lot less frequently, or ideally, 
> stop entirely. At least if you want your consumers to keep up (and you 
> clearly do or you would not have restricted access to Qt 5.15 LTS).
> You should plan for Qt 6.x releases (rather than 7.x) for at least 10 more 
> years, if not indefinitely.

I second this, considering the breakages in APIs and behavior, and bugs 
introduced, in Qt 6, I feel discussions about Qt 7 send a very poor signal. 
Porting to Qt 6 is a huge and costly effort. With so much care being made not 
to break BC, I would hope more care would be taken to preserve behavioral 
(QVariant/QMetaType) and API compatibility. I hope KDE not using Qt 6 yet sends 
a message taken seriously on the Qt side. Stay on Qt 6 for a long time guys.

Andreas
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting forward BC exception for QtWaylandCompositor in 6.2 and 5.15

[Andreas Aardal Hanssen]

On Tue, Feb 15, 2022, at 19:46, Thiago Macieira wrote:
> On Tuesday, 15 February 2022 09:34:35 PST Marc Mutz wrote:
> > 6.2 is an LTS release, is it not?
> 
> Not from my point of view, it isn't.

*cough* *cough*

Can this be commented officially by the chief maintainer?

Andreas

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

Re: [Development] Nominating Volker Hilsheimer as co-maintainer of Qt Widgets

[Andreas Aardal Hanssen]

+1 

On Tue, Jan 25, 2022, at 10:30, Oliver Eftevaag wrote:
> +1!
> 
> 
> *From:* Development  on behalf of Lars 
> Knoll 
> *Sent:* Tuesday, January 25, 2022 9:55 AM
> *To:* Fabian Kosmale 
> *Cc:* Qt development mailing list 
> *Subject:* Re: [Development] Nominating Volker Hilsheimer as co-maintainer of 
> Qt Widgets 
>  
> +1!
> 
> Cheers,
> Lars
> 
> > On 25 Jan 2022, at 09:46, Fabian Kosmale  wrote:
> > 
> > +1
> > 
> > Volker has been doing a great job fixing issues, stabilizing tests and 
> > improving the unit test coverage in the Widgets module
> > 
> > 
> > Von: Development  im Auftrag von 
> > Richard Gustavsen 
> > Gesendet: Dienstag, 25. Januar 2022 09:38
> > An: Qt development mailing list
> > Betreff: [Development] Nominating Volker Hilsheimer as co-maintainer of Qt 
> > Widgets
> > 
> > Hi all!
> > 
> > I would like to propose a change in the maintenance of Qt Widgets [1]. I’m 
> > the current maintainer of the module, but I’m happy to inform you that 
> > Volker Hilsheimer has agreed to join me as a co-maintainer. Volker is one 
> > of the biggest contributors to Widgets [2], and has been helping out 
> > maintaining the module for a long time already. So let’s make it formal as 
> > well!
> > 
> > [1] https://wiki.qt.io/Maintainers#Qt_Maintainers
> > [2] 
> > https://codereview.qt-project.org/q/owner:volker.hilsheimer%2540qt.io+repo:qt/qtbase+status:merged
> > 
> > Best Regards,
> > Richard Moe Gustavsen
> > Principal Engineer
> > The Qt Company
> > Oslo, Norway
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Erroneous Qt TouchBegin event to QGraphicsView ?

[Andreas Aardal Hanssen]

> 3. aug. 2017 kl. 04.54 skrev Patrick Stinson :
> Hi there!
> I am seeing a QEvent::TouchBegin being sent to the QGraphicsView viewport (on 
> Mac) when moving the mouse into or out of the view with no buttons pressed. I 
> noticed this because if a QLineEdit somewhere else on the window, and then I 
> move the mouse over the view, the line edit loses focus within the last line 
> in the following code block in Application::notify, where “widget” is the 
> QGraphicsView viewport.
> At other times this same block is called (indicating a TouchBegin event) when 
> I simply move the mouse outside the view again.
> What gives? The stack trace doesn’t include the generation of the touch event 
> so I can’t infer the conceptual policy here. Seems like line edit should at 
> least retain focus when not clicking or dragging anywhere.

Hi Patrick, if you file a bug on bugreports.qt.io with the above info, we can 
track it and see if someone can find the cause of the error you are seeing. If 
can be anything from phantom touch events from your Mac to bugs in application 
or library or system software. Best we try to isolate the error. 
(qt-development is more for discussion on the development of Qt, than use of 
it). :-)

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

Re: [Development] Widgets maintainers

[Andreas Aardal Hanssen]

> 7. jul. 2017 kl. 13.03 skrev Frederik Gladhorn <frederik.gladh...@qt.io>:
> Hello all, hello Marc,
...
> Our proposal is:
> Richard Gustavsen as overall maintainer
> Gabriel de Dietrich for styles
> Jan-Arve Sæther for layouts
> Eskil Abrahamsen-Blomfeldt for all text related things
> Andreas Aardal Hanssen for graphicsview


Go widget team? ;-)

Andreas

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

Re: [Development] Using semicolons in JS (QML)

[Andreas Aardal Hanssen]

2016-09-30 14:19 GMT+02:00 Kai Koehne :

> To make a proposal: Let’s use semicolons in imperative JS parts of QML in
> our examples and documentation.
>
> Apart from being on the safe side regarding some pathological cases, it
> also makes the difference between declarative QML bindings  and
>
> imperative JS code more explicit.
>

I propose to have semicolons based on the following rules:

1. Every second line of js outside of any scope should end with a semicolon.
2. Semicolon for multiline statements inside an if.
3. If whitespace isn't clear enough, add one semicolon to make the code
more readable.
4. If the semicolon makes you feel angry, feel free to arbitrarily add (or
remove) semicolons to make you feel better.

For example:

a = b // ok
a = c; // ok, since it's every second line
a = d; // WRONG drop the semicolon, be consistent for goodness sake
; // good, add a semicolon to emphasize the whitespace
;;; // now you're just being ridiculous
if (a === b) {
a = b;
a = c; // very good!
}

Andreas :-) just trying to help
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] commas in ctor-init-lists

[Andreas Aardal Hanssen]

> Den 1. jun. 2016 kl. 15.06 skrev Mark Gaiser :
> ...
> Funny in the coding style you mention. For operators: "An operator at the end 
> of the line is easy to miss if the editor is too narrow." The exact same 
> could be said for commas at the end of the line.

Silly point, it's pretty much a given that there is a comma there, it's 
insignificant. But the precise operator makes all the difference.

+1 Marc, who cares if the diff is shorter or easier to read if the _code_ is 
hard to read. And butt-ugly code is hard to read. Code is easiest to read if it 
resembles English
, and commas at the beginning of a line just doesn't.

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

Re: [Development] New KDE Free Qt Foundation agreement and changes to Qt

[Andreas Aardal Hanssen]

2016-01-13 12:15 GMT+01:00 Knoll Lars :

> Hi everybody,
> The Qt Company has over the last days signed a new and updated agreement
> with the KDE Free Foundation. With this new agreement come some adjustments
> to the open source licensing of Qt. Basically LGPLv3 will in the future be
> our main license for frameworks, GPLv3 for the tooling.
> At the same time, The Qt Company committed to open source the currently
> commercial only parts of Qt for Application Development under the GPLv3 and
> make those available to the open source community.
> I have discussed this change with many of our Maintainers over the last
> week, getting a lot of positive feedback to this change.
>

With Qt 5.6 being LTS and 5.7 removing licenses from modules, is there
enough thunder in 6.0 to get people away from the cooosy 5.6 release? ;-) I
mean - judging solely on historical events, the .0s have needed some time
to stabilize and the big bang features typically don't show up in the very
latest minor releases.

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

Re: [Development] Backwards compatibiltiy break in Qt 5.5

[Andreas Aardal Hanssen]

2015-07-28 9:50 GMT+02:00 Robert Iakobashvili corobe...@gmail.com:

 On Tue, Jul 28, 2015 at 11:48 AM, Marc Mutz marc.m...@kdab.com wrote:
  On Monday 27 July 2015 20:44:48 Thiago Macieira wrote:
  On Monday 27 July 2015 21:41:44 NIkolai Marchenko wrote:
   Yes,but this requires making override visible in every file of the
   project.
  We can solve this by having a global #ifdef that can change the setting.
  Or an environment variable, so you don't have to recompile the world...
 Yes, it's a good idea to have an environment variable or
 a pre-processing flag to preserve the existing behavior.
 In Qt 5.* the default could be the old behavior,
 and in Qt 6 - the new.


Isn't this needless convenience? Yet another environment variable that
needs documenting? If you want to inspect the contents of a QString, can't
you just add the suitable escape code to your own code? Forcing
qPrintable() or qUtf8Printable() on everyone who wants to keep human
readable debug output sounds pretty evil, but having e.g. toHtmlEscaped()
or a similar function doing the octa/hex thing could be better.

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

Re: [Development] Backwards compatibiltiy break in Qt 5.5

[Andreas Aardal Hanssen]

 On 27 Jul 2015, at 21:14, Thiago Macieira thiago.macie...@intel.com wrote:
 
 On Monday 27 July 2015 21:50:15 NIkolai Marchenko wrote:
 Oh, but now you KNOW that it is a misspeled link to paypal. In real
 situation you won't have this forward knowlegde.
 
 The point is that I have all of the information I need. If I see a debug 
 output saying:
 
 ClassName::openLink: trying to open \u0440\u0430\u0443\u0440\u0430l.
 \u0441\u043em

Thiago what was the original cause for the change? Shouldn’t a change like this 
be argued in, rather than out?

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

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Andreas Aardal Hanssen]

 On 12 Jul 2015, at 16:58, Marc Mutz marc.m...@kdab.com wrote:
 That's because your benchmark runs entirely in L1.
 If you want to test containers of 10, 100, 1000 and 1 elements each, then 
 make
 - one run over 1×N containers of 1 elements each,
 - one run over 10×N containers of 1000 elements each,
 - one run over 100×N containers of 100 elements each,
 - one run over 1000×N containers of 10 elements each.

This is getting defensive, and quite frankly, a bit boring. The fact that half 
of the emails are from one author defending his absolute view with increasingly 
complex arguments suggests action points be taken and the debate be closed.

Clearly Marc should write a /book/ about which tricks should be applied when 
writing high performance code. It’s non-trivial, and it really is no 
container’s role to be the sole solution to everything. There’s also no such 
book out there but clearly many “undocumented tricks” and pitfalls.

We can’t add tables, and complex explanations, or dynamic forms where you input 
your sizes and types, to Qt docs to “help” people choose the right container. 
Complex docs == bad docs. Writing high performance code requires a touch of 
genius, and only needs to be applied to choice of algorithms at the highest 
level and only the most important loops at the lowest level. The performance of 
QList isn’t the prime focus of people writing normal code. Paint engine 
insides, for example, we make an effort not to allocate memory at all from 
begin to end. That sort of rules out most container classes out there.

Suggested actions points:

1. Update Qt docs to indicate that careful planning, perhaps a pointer to 
Marc’s blog, this thread, and QVector docs, could be useful when writing 
performance critical code. I’m certain QList will be just a tiny chapter in 
Marc’s upcoming book but link to that chapter.

2. Analyze (again) when is the time to make Qt’s containers simple wrappers 
over those of stl and/or boost. Performance differences over equivalent classes 
with different APIs should be limited to the API differences themselves. 
Nothing else makes sense.

3. Marc, consider writing that book. It’s not a general book on Qt, because Qt 
is about writing code simple quick and easy with acceptable performance, not 
how to squeeze every cycle out of every part of your code.

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

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Andreas Aardal Hanssen]

 On 10 Jul 2015, at 14:58, Marc Mutz marc.m...@kdab.com wrote:
 On Friday 10 July 2015 13:37:40 Andreas Aardal Hanssen wrote:
 QListQImage.
 You just proved my point. sizeof(QImage)  sizeof(void*). If even you as a 
 long-time Troll don't understand what QList actually does, there's a problem. 
 Don't you agree?

At the very worst it would be a bug if QList created a list of pointers to new 
QImages. I can’t say when that bug was introduced though.

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

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Andreas Aardal Hanssen]

 On 10 Jul 2015, at 14:24, Marc Mutz marc.m...@kdab.com wrote:
 That just goes to show how bad of an influence QList has. But it never hid 
 its 
 design, and, indeed, the default container in Qt 3 was QValueList, which 
 actually *was* a doubly-linked list. Why Qt always nominates a list as the 
 default container while the STL recommends std::vector is one of the 
 mysteries 
 to which only Trolls know the answer :)


QList is the perfect default container for applications that value convenience 
and intuitiveness over best performance (a typical feature for most APIs in 
Qt), but it still outperforms arrays and linked lists for the most common 
operations for complex types, such as insertion and removal. The two most 
useful examples of QList usage in Qt applications are QListQWidget *, and 
QListQImage. To cater for the problem of custom complex types, all types in 
Qt were made shallow (the shallowness of containers and smartness of QList when 
used with shallow types go hand in hand, which is another typical feature for 
APIs in Qt). It should be no surprise to users that creating a QList of 100 
QImages does *not* lead to 100 news or mallocs.

Qt APIs also help programmers avoid making mistakes. QList has the undisputable 
advantage of allowing lists of dynamic sized elements. It’s a common 
programmer’s mistake to run into trouble with lists of dynamic elements when 
those elements are stored in arrays. Trouble leads to hacks leads to bugs. It 
doesn’t take too much imagination to understand how much of a pain you can run 
into, and what horrors could be applied to work around, creating a QVector of 
QVectors. The problem is a bit hard to grasp for some developers, and using 
QList you just don’t run into those problems.

So, I dispute the general -1 of any use of QList. Use yours brains, and -1 
where brain has not been applied. ;-)

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

Re: [Development] Fwd: QTextStream::readLine(0) is an ambiguous overload in 5.5

[Andreas Aardal Hanssen]

2015-05-18 14:56 GMT+02:00 Alejandro Exojo s...@badopi.org:

 El Monday 18 May 2015, Smith Martin escribió:
  You omitted that toInt(ok) is required to test ok for null, which is not
  required if ok is a reference.
 That's extra work in the implementation in order support a nicer API to the
 users, e.g. to support toInt() with the null value as default argument, in
 addition to the passing a pointer makes clear that the value could be
 modified.


Very true! In fact the opposite API to toInt() was chosen in
QIODevice::getChar() to ensure that even the extra line of testing for OK
on the client side could be eliminated. For toInt(), it's rare that the
output arg needs to be tested, but for QIODevice::getChar(), it's the
opposite.

char ch;
if (device-getChar(ch)) {
// foo
}

http://doc.qt.io/qt-5/qiodevice.html#getChar

Imagine reading code like this:

char ch;
if (device-getChar(ch)) {
// foo, wtf is ch for??
}

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

Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5

[Andreas Aardal Hanssen]

2015-05-18 11:40 GMT+02:00 André Somers an...@familiesomers.nl:

  Andreas Aardal Hanssen schreef op 18-5-2015 om 11:35:

   Qt convention is to promote pointers for out parameters to make it
 immediately clear that your input can be modified. Out references, or
 non-const reference parameters, have traditionally been discouraged because
 they make the code harder to read. It's not about what's proper C/C++.

 Pointers can be just as opague. In terms of the above example: I cannot
 see from any of the parameters to those functions what their types are. If
 they are already pointers, they may already get modified. On the other
 hand: that pointer may not get modified at all.
 I created https://bugreports.qt.io/browse/QTCREATORBUG-14468 for some
 tooling support to get a better feedback on what's going on.


At the end of the day, tmp is always a pointer, whereas tmp may not be.
It's simply easier to read. Having reference out parameters is a API design
mistake in Qt. Agree or not but deviating from this makes for an
inconsistent API.

Andreas

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

Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5

[Andreas Aardal Hanssen]

2015-05-18 11:10 GMT+02:00 Christian Kandeler 
christian.kande...@theqtcompany.com:

 On 05/17/2015 09:57 PM, Giuseppe D'Angelo wrote:
  On Sun, May 17, 2015 at 9:55 PM, Smith Martin
  martin.sm...@theqtcompany.com wrote:
  How do you get bitten by an out-reference?
  As usual, because at call site I didn't realize the argument was
  actually being modified. Compare
  doSomething(param1, param2, param3);
  doSomething(param1, param2, param3);
  which one is likely to be modifying arguments?
 Both are equally likely to, unless you are a C programmer.


Qt convention is to promote pointers for out parameters to make it
immediately clear that your input can be modified. Out references, or
non-const reference parameters, have traditionally been discouraged because
they make the code harder to read. It's not about what's proper C/C++.

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

[Development] Fwd: QTextStream::readLine(0) is an ambiguous overload in 5.5

[Andreas Aardal Hanssen]

2015-05-18 11:54 GMT+02:00 Smith Martin martin.sm...@theqtcompany.com:

  When I'm reading code and I encounter a function call with parameters,
 if I am not familiar with that function, I look at its documentation. First
 I look at the signature. If it contains a non-const reference, I know the
 parameter can be modified. I read the function documentation to see if it
 is meant to be modified.

 What is required inside the function if a pointer is used instead? Is the
 function required to test the pointer for nil and return in an error state
 or report an error? That doesn't happen with a reference.


Hi Martin :-).

IMO Qt's first level of helpfulness is its API. The code should be
self-explaining and self-documenting if possible. Then, if you cannot
figure out what a function does, Qt provides first class documentation.
Which is why QList has append and prepend instead of push_back and
push_front :-).

bool ok = false;
int foo = variable.toInt(ok); // need doc
int foo = variable.toInt(ok); // dont need doc

Again though, this is procrastinating. Unless something significant has
changed in C++ the last 10 years with regards to pointers and references
I'd just continue sticking to what has always been the convention.
Otherwise going through all Qt's api and changing it from pointers to
references would be required. IMO.

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

Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5

[Andreas Aardal Hanssen]

2015-05-18 12:07 GMT+02:00 Julien Blanc julien.bl...@nmc-company.com:

 C++, you should resort to const-correctness to prevent mistakes. I like


There is no const correctness in C++. #dontfeedthetroll
#trymakingaconstcorrectlinkedlistinc++

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

Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5

[Andreas Aardal Hanssen]

2015-05-18 13:46 GMT+02:00 Marc Mutz marc.m...@kdab.com:

 On Monday 18 May 2015 12:17:32 Koehne Kai wrote:
  Can you elaborate? We're talking about in/out parameters here, where
  raw pointers IMO are still perfectly valid. What do you expect the
  signature  of readLine(QString *line) to be in C++14?
 QString readLine(QString reuseThisStringsCapacity);


The overload is unintuitive and the operation so complex that I would
propose doing something different altogether. It's no longer a one-liner.
It's not a good case for out parameters at all...

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

Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Andreas Aardal Hanssen]

Sigh get a room (on irc fex) guys. Mailbox full already ;-).

Andreas Aardal Hanssen

 Den 20. jan. 2015 kl. 17.08 skrev Thiago Macieira thiago.macie...@intel.com:
 
 On Tuesday 20 January 2015 11:28:10 Oswald Buddenhagen wrote:
 So no, don't tell us qtchooser is not meant to solve distros'
 problems. It's meant exactly for them.
 
 but i do. my purpose was to keep the imo (slightly) detrimental change
 out of qt, and enabling our developer use case to be convenient. i never
 considered the distro case relevant as such - i demonstrated why it is a
 non-issue back then, and i did it again in my previous mail. there is
 simply no problem that needs solving upstream. the fact that fedora
 successfully ships qt5 packages proves this.
 
 I do remember you dismissing the distro's setup as an argument. I also 
 dismissed your dismissal.
 
 -- 
 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] FTP in Qt5

[Andreas Aardal Hanssen]

On 08 Mar 2014, at 18:11, Thiago Macieira thiago.macie...@intel.com wrote:
 Em sáb 08 mar 2014, às 08:31:19, Tom Isaacson escreveu:
 There are no plans. FTP is really low-priority these days.
 Well we're still using it. Plus I said resume functionality for HTTP and FTP
 - I still think resume is an important part of any downloader so you don't
 end up having to download the same data. Is there no interest in this?
 Interest, yes. But it's a low-priority because QFtp can't resume. You can't 
 send a command that might fail because QFtp will abort the connection.
 In order to support resuming file transfers, supporting IPv6, not to mention 
 directory listing, we'd need to rewrite the backend from scratch. That's the 
 low priority. Don't expect it to happen, at all.


When you say “we”, do you mean the Digia or the Intel Qt developers, or the 
community?

If someone, including the requesting party themselves, does such work, I’m sure 
there are reviewers / approvers ready to do the reviewing.

Part of the good thing of the contribution model is that effort follows the 
priority of the contributor. I don’t think it’s fair to use the term “we don’t 
think it’s important” anymore.

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

Re: [Development] Accepted flag of QGraphicsView::mouseMoveEvent is not updated

[Andreas Aardal Hanssen]

On 19 Jan 2014, at 16:34, Dmitrii Volosnykh dmitrii.volosn...@gmail.com wrote:
 Probably we may discuss it before make any unwanted bug reports...
 Basically, I have the same problems described in the referenced topic from 
 URL. Specifically, I have a scene (tiles of geographic map) and an overlay 
 consisting of a polyline which should be editable via dragging its vertices.
 By default, map is translated when mouse is moved with left button being 
 pressed. It should not do so when some of the polyline's vertices is being 
 dragged. This is where the problem comes up. As for now, while draging vertex 
 the map is translated at the same time. Of course, this looks weird. So, I'd 
 like to have some means to distinguish the case when QGraphicsScene processes 
 (or one of its QGraphicsItem's) mouse move event and when it is not. I could 
 rely on QEvent::isAccepted() flag, but it is true everytime.
 As for your statement that current behaviour is correct: what do you think 
 about changes done as a result of resolving QTBUG-8061 
 (https://bugreports.qt-project.org/brows/QTBUG-8061)? See 
 https://codereview.qt-project.org/#patch,sidebyside,61740,2,src/widgets/graphicsview/qgraphicsview.cpp
 This patch is right what I lack for mouseMoveEventHandler() to do for me, in 
 case this is consistent with desired behaviour.

Sounds to me like you want the behaviour to change based on what you press. 
QWidget’s mouse event propagation policy is different from graphics view’s. In 
graphics view, if the press is rejected, the move is never delivered, 
regardless. If an item on the scene does get a move, that’s because the item 
accepted the press. So, the move is always accepted.

The bug above is about press / double-click - so it’s not related.

If you want to discuss the behaviour further, I think it’s best to create a new 
bug report, which includes the code in question.

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

Re: [Development] QWidget mouse events - different order

[Andreas Aardal Hanssen]

Why keep the breakage though. This fix would still require a note in
porting docs and changes to code. Why fix what was never broken - just
go back to Qt 4 behavior..

Sorry for the post format, crap mail client issue...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Howto know the Qt version in Qt source code

[Andreas Aardal Hanssen]

On 30 Dec 2013, at 09:31, Li Anthony anthony...@digia.com wrote:
 Hi,
 Maybe this is a silly question. But I always want to know the Qt version when 
 I compile Qt from source code. Is there a version file or some easy way that 
 I can find in source code?
 Thanks.
  

http://linux.m2osw.com/find-qt-version-command-line-compile-time-run-time

Googled “find Qt version” :-). There are lots and lots of hits.

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

Re: [Development] [Request] Add Info to QDebug

[Andreas Aardal Hanssen]

On 23 Dec 2013, at 14:42, Thiago Macieira thiago.macie...@intel.com wrote:
 Fatal conditions affect not only the application, but also the surrounding
 system. The application and possibly the whole system should be shutdown
 immediately. A good example is loss of control of an X-ray beam in an X-ray
 scanner. Even in this situation, just kicking out the application is very
 often not a good option. It often should start an emergency procedure.
 I don't see the difference between fatal and critical when looking at a 
 single 
 application. If the application can't continue, it's fatal for the 
 application: it's dead. We use qFatal to log situations that terminate the 
 application.

qFatal has the unfortunate side effect that it ties application termination 
(quit now) to logging once. An error may well be critical without that meaning 
that printing the error should cause immediate harakiri. I stick by qFatal 
being for programmers only, as an alternative to assert, but which triggers in 
release also. Criticial log level is nice if you want to first print this, then 
that, then foo, then bar, then cleanup, then quit.

FTR, I’m completely -1 for touching QDebug and friends, and +1 for adding a 
proper logging framework. QDebug, qWarning, qCritical and qFatal are for 
programmers, not administrators who want app log output for system maintenance.

In our app environment, we have (as many else!) added our own LogInfo()  
“bar”, which formats the log output according to our system-wide standard. That 
makes the logs parseable to all our internal tools. We also override Qt’s debug 
handlers to ensure that any use of qDebug, warning, critical or fatal ends up 
properly formatted. I.e. the the debug handler uses our Log thing.

Andreas

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

Re: [Development] [Request] Add Info to QDebug

[Andreas Aardal Hanssen]

On 23 Dec 2013, at 21:39, Kurt Pattyn pattyn.k...@gmail.com wrote:
 On 23 Dec 2013, at 17:38, development-requ...@qt-project.org wrote:
 From: Andreas Aardal Hanssen andr...@hanssen.name
 Subject: Re: [Development] [Request] Add Info to QDebug
 Date: 23 Dec 2013 15:17:06 GMT+1
 To: development@qt-project.org
 FTR, I’m completely -1 for touching QDebug and friends, and +1 for adding a 
 proper logging framework. QDebug, qWarning, qCritical and qFatal are for 
 programmers, not administrators who want app log output for system 
 maintenance.
 I think that QDebug can be a sound foundation for a ‘proper’ logging 
 framework.

That’s as silly as saying the same for printf, or cout. Sorry but I really 
disagree with you. In Java you also don’t see system.out.println used in any of 
the major log frameworks there.

 In our app environment, we have (as many else!) added our own LogInfo()  
 “bar”, which formats the log output according to our system-wide standard. 
 That makes the logs parseable to all our internal tools. We also override 
 Qt’s debug handlers to ensure that any use of qDebug, warning, critical or 
 fatal ends up properly formatted. I.e. the the debug handler uses our Log 
 thing.
 So, programmers log messages do finally end up in the logs. By using 
 qSetMessagePattern it is possible to format the log output as well.

We have to do that, otherwise they end up as console output, which isn’t seen 
anywhere. And no, qSetMessagePattern does nothing to solve our problem. This 
approach solves the problem the right way - redirecting programmer noise into a 
proper logging framework.

 By only using q(C)Debug(), q(C)Info(), … there is a single API to do logging.
 By implementing a proper logging backend, Qt could have plugins to log to 
 (r)syslog(-ng), Windows Event Log, slog2, aso, and then there would be an 
 almost perfect fit for qDebug(), qInfo(), …


Gah, rather I’d see activity on the project referred to by Thiago. qDebug isn’t 
a logging framework, it’s just what you use to print debug info to the console.

That’s pretty much my input to this thread..

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

Re: [Development] QWidget mouse events - different order

[Andreas Aardal Hanssen]

On 20 Dec 2013, at 09:15, Martin Koller kol...@aon.at wrote:
 so it's just the extra mousePressEvent in Qt5 which is wrong.

Good. I think it can and should just be removed, but it would be nice to know 
when it broke, in case there was thought behind it...

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

Re: [Development] QWidget mouse events - different order

[Andreas Aardal Hanssen]

On 19 Dec 2013, at 03:30, Nicolás Alvarez nicolas.alva...@gmail.com wrote:
 That would break many use cases, such as QSpinBox, which performs an
 action on every press (not release) and doesn't care about double
 click events.

No it wouldn’t. The default implementation of mouseDoubleClickEvent() calls 
mousePressEvent().

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

Re: [Development] Qt's Leak-on-exit policy

[Andreas Aardal Hanssen]

On 19 Dec 2013, at 11:29, Tim Blechmann t...@klingt.org wrote:
 Should Qt clean-up dynamically allocated reachable pointers, or is this
 useless / pointless work?
 [snip]
 2) static leak, which is when the pointer is overwritten at shutdown without 
 being freed
 i wonder: what is the definition of shutdown?
 in many applications it is perfectly fine to allocate memory without
 freeing them ...

Worth mentioning that freeing memory takes no time, so skipping freeing memory 
to optimize shutdown time is just silly.

It’s the C++ism of destroying an object that takes time in connection to 
freeing memory. Complex destructors are one of two things that makes an app 
slow to quit, beyond whatever the app _wants_ to do on shutdown. The other case 
where an app would spend measurable time on a clean shutdown is if it has dirty 
written pages to mapped memory that need to be flushed.

Should apps explicitly free all memory, that’s not only about tracking 
ill-managed memory. If your app manages its memory well, explicit freeing is 
irrelevant for the app as it stands. Whether you ask the OS to reclaim the 
memory or not before it does so itself does nothing for shutdown time. But it’s 
impractical to fail to free memory on exit, because it makes it darn hard to 
discover ill-managed memory. And since freeing memory is so connected to 
destroying objects in C++, and running destructors, failing to explicitly free 
memory will typically also fail to call those destructors.

It’s rare to find a C++ class with a non-empty destructor that takes into 
account what could happen if the memory were freed, as it always is, but the 
destructor was not run.

+1 to explicitly destroying / freeing all memory. It does nothing for shutdown 
time, but makes it easier to discover ill-managed memory. And destructors 
should always be called for any instance of a class that has a destructor 
implementation.

This goes for real-world apps btw, in examples / snippets in books / online and 
so on, memory management is just noise.

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

Re: [Development] QWidget mouse events - different order

[Andreas Aardal Hanssen]

On 19 Dec 2013, at 18:36, Rick Stockton rickstock...@reno-computerhelp.com 
wrote:
 Perhaps we should perform as QT4 did (there wasn't a second ButtonPress,
 the DoubleClick ate it). Such use cases would then need to be fixed
 up (i,e, to accept EITHER event as a cause for executing that Action)?
 Logical, but a lot of work.

Keeping Qt 5’s current behavior makes it impossible for an app to distinguish 
between multiple presses and a double-click without duplicating the timers in 
QApplication. Applications that rely on the original behavior are likely to be 
confused by the state you enter when receiving the second press.

http://qt-project.org/doc/qt-5.0/qtwidgets/qapplication.html#doubleClickInterval-prop

Sending the press event before the double click looks like a mistake, I wonder 
if it’s the same on all platforms. I would be surprised, as it would break all 
apps that handle more than simple mouse events. A git bisect is probably a good 
idea...

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

Re: [Development] QWidget mouse events - different order

[Andreas Aardal Hanssen]

On 18 Dec 2013, at 22:07, Rayner Pupo Gómez rpgo...@uci.cu wrote:

 I've discovered that with Qt5 I get a different order of mouse events on
 a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
 double clicking a widget results in Qt4 in:
 mousePressEvent 
 mouseReleaseEvent 
 mouseDoubleClickEvent 
 mousePressEvent 
 mouseReleaseEvent
 but in Qt5 in:
 mousePressEvent 
 mouseReleaseEvent 
 mousePressEvent 
 mouseDoubleClickEvent 
 mouseReleaseEvent 
 I tested with Qt4.8.5 and Qt5.2.
 Is this behavioral change intended, undefined, a bug ?
 (it results in my app not behaving as before ...)
 -- 
 
 I think it's a mistake to rely on the order of this kind of events, there are 
 fired asynchronously, your logic cant depend on this

Wrong! The order is very essential and can and must be relied on.

The behaviour in Qt 5 is questionable. I believe the double-click must come 
first to be able to distinguish from two presses.

I also wonder if it’s accurate / true that Qt 4 sends the second press after 
the double-click. AFAIR:

Press
Release
DoubleClick
Release

Is the right events for double-clicking.

Andreas

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

Re: [Development] Weird offseting in QDataStream

[Andreas Aardal Hanssen]

On 08 Nov 2013, at 10:15, Yves Bailly yves.bai...@sescoi.fr wrote:
 Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit :
 See QDataStream::setFloatingPointPrecision. The default is double.
 That's pretty strange... what if I want to read a float then a double? do I
 have to switch between the two each time?
 Does this means it's impossible to use code like this:
 float f;
 double d;
 datastream  f  d;

QDataStream stores your content in a portable binary format. Specifying the 
floating point precision makes it clear that real numbers, be them represented 
in floats or doubles in C++, are stored as floats or doubles in file.

If you want to store a float as a float, and then a double as a double, you 
need to change the precision of QDataStream in between calls. Plus, the code 
that reads the file must match the code that wrote the stream.

Andreas

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

Re: [Development] Weird offseting in QDataStream

[Andreas Aardal Hanssen]

On 08 Nov 2013, at 11:32, André Somers an...@familiesomers.nl wrote:

 Eskil Abrahamsen Blomfeldt schreef op 8-11-2013 11:20
 
 QDataStream supports reading and writing floats and doubles, but it
 might use more bytes than necessary to represent them in the stream.
  the main ...
 I don't see what's wrong with such a mode, as long as the documentation 
 warns that it won't work reliably with qreal (before 5.2, I read). You

To me it sounds like Qt needs a new lower-level class for serializing and 
deserializing stuff.

QDataStream is for Qt only, it’s incompatible with all other binary formats out 
there, with the undocumented exception for cases where primitive types match.

I would recommend against using QDataStream for anything else than reading back 
what was written using QDataStream.

Andreas

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

Re: [Development] Weird offseting in QDataStream

[Andreas Aardal Hanssen]

On 08 Nov 2013, at 12:41, Yves Bailly yves.bai...@laposte.net wrote:
 ]I would recommend against using QDataStream for anything else than reading 
 back what was written using QDataStream.
 This is what I called a step backward.

It’s just stating a fact. QDataStream isn’t a generic cross-framework class, 
it’s not based on any standard. Its internal structure is completely 
undocumented. It’s compatible only with itself, and then, only with specific 
versions of itself. It even encodes the QDataStream format version in the 
stream itself.

So it’s not a step backward. It’s just a special-purpose class used for more 
than it’s designed for.

Personally I think using fstream or htons is perfectly fine. Both are portable, 
beyond what QDataStream does.

Andreas


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

Re: [Development] QCommandLineParser

[Andreas Aardal Hanssen]

 instance to
  print out the builtin options.
  So, this needs no new API either to mark these options as the ones for
  --help- qt, they are already separated in a different internal-only
  parser, not mixed with the application options.
 
  By the time we want to create a command-line parser internally in
  QCoreApp, we can sort out the translation setup -- possibly like in
  KDE where the translators got automatically loaded from standard
  paths, which means tr() can be used inside the qapp constructors.
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development




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

Re: [Development] Nominating Andreas Hanssen as Approver

[Andreas Aardal Hanssen]

Thanks Lars and all!

Indeed I can! Yohoo!

Andreas

2013/3/4 Knoll Lars lars.kn...@digia.com

 Congratulations Andreas!

 I should have just fixed the permissions in Jira. Andreas, can you check
 that you can now edit bugs etc.?

 Thanks,
 Lars

 On 2/28/13 11:29 PM, Laszlo Papp lp...@kde.org wrote:

 Yes. See these for an examples:
 
 https://bugreports.qt-project.org/browse/QTJIRA-195
 https://bugreports.qt-project.org/browse/QTJIRA-178
 
 On Thu, Feb 28, 2013 at 8:09 PM, Thiago Macieira
 thiago.macie...@intel.com wrote:
 
 It's been 15 work days. Congratulations Andreas!
 
 PS: how does one get the necessary privileges in JIRA? Do we have to
 create a
 QTJIRA task?
 
 On quarta-feira, 6 de fevereiro de 2013 13.31.40 tel:2013%2013.31.40,
 Thiago Macieira wrote:
  Hello
 
  Andreas is a long-time Qt developer. For those of you who haven't yet
 had
  the pleasure of meeting him, he's the brains behind the original
  implementation and maintenance of Graphics View. Before that, I remember
  working with him on the networking classes -- in fact, QSslSocket is
 also
  his and George Staikos's.
 
  His knowledge is invaluable.
 
  You can find him on IRC under the nickname bibr.
 
  His dashboards:
https://codereview.qt-project.org/#dashboard,1000351
https://codereview.qt-project.org/#dashboard,1001692
 
  More importantly, the list of reviews:
https://codereview.qt-project.org/#q,reviewer:
  %2522Andreas+Aardal+Hanssen%2522,n,z
 --
 Thiago Macieira - thiago.macieira (AT) intel.com http://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

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




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

Re: [Development] Nominating Andreas Hanssen as Approver

[Andreas Aardal Hanssen]

2013/2/7 Eirik Aavitsland eirik.aavitsl...@digia.com

  +1 of course
  Also a bit surprised to hear that he's not already an approver. :)A
 distinguished developer like Andreas does not deserve this BASIC-like
 +1 syntax. I say:
 ++
 and strongly, too :)


Shucks guys ;'-) you're the best!

Ready to pay back some of the work you have all done to getting my stuff
approved.

Qt rocks!

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

Re: [Development] Help needed in 4.8 failing tests on Mac (QGraphicsProxyWidget and MacNativeEvents)

[Andreas Aardal Hanssen]

On Dec 29, 2012, at 3:10 PM, Thiago Macieira thiago.macie...@intel.com wrote:
 The following two tests have prevented 3 of the last 6 integration in 4.8, 
 and 
 that's 3 of 3 of the integrations that failed on Mac:
 
 These are consistent failures: they failed in 6 out of 6 runs:
  FAIL!  : tst_QGraphicsProxyWidget::hoverEnterLeaveEvent(widget, no hover) 
  FAIL!  : tst_QGraphicsProxyWidget::hoverEnterLeaveEvent(widget, hover)

These tests can all be rewritten - they do not need to rely on the rather 
flaky[*] behavior of QWidget's events. Fixing them means sending the expected 
events directly to the scene, instead of waiting for the view to send them. 
This simplifies the tests and makes them 100% reliable but it sort of requires 
there to be tests for QWidget that do test that these events are delivered 
under more stable/reliable conditions.

I'm all for making this simplification, it can also simplify and stabilise 
other similar graphics view test cases. It narrows the scope of the tests but 
that may not be a problem.

Andreas

[*] The flakiness isn't visible to the user, typically it's caused by relying 
on windows being activated exactly once, and is also sensitive to the initial 
position of the mouse cursor when a widget is initially shown (as if the widget 
is already under the cursor when opened, the HoverEnter event may have been 
received before the test expected it to, and so on).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] FW: how to improve GraphicsView performance

[Andreas Aardal Hanssen]

2012/8/21 Konstantin Tokarev annu...@yandex.ru

 21.08.2012, 12:24, song.7@nokia.com song.7@nokia.com:
  I’m using QGraphicsView to implement google weather in a low-end(CPU:
 300MHz) hardware. All are nice except the performance.
 Wether 300 MHz is low-end or not, is highly dependent on architecture.
 E.g. 300MHz SPARC may be not bad at all.
  Is there any other idea? Thanks!
 Maybe you should use custom QWidget implementation with finely tuned
 repaint logic instead of GraphicsView.


 That won't likely solve the problem, but will probably cause lots of more
work ;-).

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

Re: [Development] Partial screen updates with Scenegraph

[Andreas Aardal Hanssen]

2012/7/20 gunnar.sle...@nokia.com

  Is it possible to set the new Grahpicsstack to do only partial screen
 updates?
  This would help me fixing some performance issues on embedded devices.Hi
 Dietrich,
 The scene graph does not do partial updates.
 Based on the experience we had from the widget stack and graphics view, we
 early on concluded that for applications which have moderate amount of
 animations, partial updates hurts a lot more than it gains.


Partial update support doesn't help for applications that don't _need_ it,
rather. And high-end mobile phones where there's enough CPU and GPU power
for the UI, which is the focus of QML 2 and the SceneGraph, don't need it.

For hardware and applications where memory bandwidth and CPU/GPU power is
an issue, for example when resolutions go above 800x480 (e.g., retina) and
there are multiple screens, with multiple layers (e.g. video playback or
animated wallpapers), supporting partial updates becomes a matter of win or
lose. Wasn't EGL_NOK_swap_region2 added for this reason?

Since SceneGraph doesn't support partial updates, those who need that
should choose QML 1 with QGV [*]. Perhaps when QML 3 comes out, there's be
a single solution to both problems ;-P.

[*] In QGV you can select QGraphicsView::FullViewportUpdate to avoid the
cost; the default being QGraphicsView::MinimalViewportUpdate which supports
disjoint viewport updates. QGraphicsView::BoundingRectViewportUpdate is a
good go-between. The cost imposed is not that bad. The example of dragging
an object around a screen without imposing full updates and complete
redraws is logical.

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

Re: [Development] Partial screen updates with Scenegraph

[Andreas Aardal Hanssen]

2012/7/20 Uwe Rathmann uwe.rathm...@tigertal.de

 On 07/20/2012 12:32 PM, Andreas Aardal Hanssen wrote:
  Partial update support doesn't help for applications that don't _need_
  it, rather. And high-end mobile phones where there's enough CPU and GPU
  power for the UI, which is the focus of QML 2 and the SceneGraph, don't
  need it.
 What about using regular desktop applications remotely ( X11, NX, VNC
 ... ), where the network bandwidth is a limiting factor. F.e. in home
 office environments you sometimes run UIs over DSL ( or even slower ).
 Isn't QML 2 the recommended API for desktop applications too ?


I think it's really important for any desktop GUI to allow efficient
desktop sharing like that. But good sharing technologies don't rely on
partial update support in each and every application.

Generally speaking, applications based on transferring graphical content
over the network like that are split into two parks: (1) Those who rely on
expose events from the gui app to optimize traffic and (2) those who use
proper video encoders / that send compressed delta updates by comparing
frames. The latter supports everything, the former is, IMO, really
inefficient and should be a thing of the past.

I think partial update support is really about the local device's
capabilities.

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

Re: [Development] Suggestion on QML portability

[Andreas Aardal Hanssen]

2012/7/17 Sven Anderson sven.ander...@snom.com

 On 17.07.2012 07:47, Alan Alpert wrote:
  But our Qt4Support library exists and is called QtQuick1. All the old
 symbols
  should be there, if you want to take the easy road to saying done,
 ported to
  Qt 5!.
 Well, there is no other choice if you have a platform without hardware
 graphics acceleration. ;-)


[OT]

Without _OpenGL_. :-) There are other flavors of hardware acceleration
APIs, I expect even more different in the future.

(2D accelerators are often bundled with GPUs and perform 2D rendering ops
faster than GPUs, but are unusable with QML 2 / SceneGraph; see pvr2d).

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

Re: [Development] Suggestion on QML portability

[Andreas Aardal Hanssen]

2012/7/17 marius.storm-ol...@nokia.com

  (2D accelerators are often bundled with GPUs and perform 2D rendering
  ops faster than GPUs, but are unusable with QML 2 / SceneGraph; see
  pvr2d).
 2D accelerators bundled with GPUs perform 2D rendering ops faster than
 GPUs? Uhmm... that sentence is conflicting in my head, unless you mean
 that you are using highly specialized boards with multiple GPUs (n*PVR)
 on them to do things really really fast in parallel.


[OT]

No, I really mean dedicated 2D hardware chips outperform GPUs by far. It's
easy to do certain common simple 2D graphics faster than most embedded GPUs
I know of, even using the CPU. GPUs are built for (1) 3D transformations on
textures, (2) vertex-heavy objects and (3) per-pixel shading operations.
But it's easily beat for simple 2D operations like blit (e.g., DMA),
filtering/scaling (e.g., FPGAs). Most mobiles / tablet UIs are 90% 2D.

My point is simply that Qt 5 is best served with a painting backend for QML
2 that can support non-OpenGL technologies.

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

Re: [Development] Suggestion on QML portability

[Andreas Aardal Hanssen]

2012/7/16 Alan Alpert alan.alp...@nokia.com

 Just brainstorming here, what if there was a QtQuick 1.2 in Qt 5 which
 provided this overlap? It would have the old method marked as deprecated
 and
 the new form syntax available and would provide some form of interim
 overlap,
 without adding functions to QtQuick 2.0. Would that ease your porting?


Just to bring the point to the table, this isn't just about _porting_.
Porting from QML 1 to QML 2 is unfortunately not just a language update.
It's also about having to move to an OpenGL only rendering environment,
which makes QML 2 useless to some graphics projects. This is why QML 1 is
still around. This topic is just as much about sharing QML code between two
independent QML projects. I'm in this situation now. I have complex state
logic that I don't want to fork or branch out in two code bases.

QML 2 should re-add the obsoleted symbols where it has no penalty to the
main API. There is no reason not to, other than causing pain to the
audience of the API. The good thing is that such APIs can be added in 5.1
and even later. But not doing so will make it harder for people to make any
use of QML 2.

In Qt 4 we added obsolete symbols for Qt 3, and this never caused any pain
for anybody. Qt3Support was a well intended effort to either port classes
that were dropped from Qt 3, or to wrap those around Qt 4 classes that
provided the same functionality. Let's make use of the good experience this
was in Qt 5 as well.

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

Re: [Development] Suggestion on QML portability

[Andreas Aardal Hanssen]

2012/7/16 Thiago Macieira thiago.macie...@intel.com

 On segunda-feira, 16 de julho de 2012 09.38.53, Andreas Aardal Hanssen
 wrote:
  In Qt 4 we added obsolete symbols for Qt 3, and this never caused any
 pain
  for anybody. Qt3Support was a well intended effort to either port classes



 Qt3Support did enable some compatibility features in QtCore and QtGui
 (especially the event loop and kernel), which means that CPU cycles would
 be
 spent for the price of having compatibility.
 We chose not to do the same in Qt 5. All the compatibility layer is made
 up of
 inline functions.


IIRC these were removed when you built Qt with -no-qt3support (e.g., was it
ChildAdded and friends), and we also never had any reports of people
complaining about the penalty imposed by leaving them in. The point I'm
trying to make is that adding obsolete symbols that call the preferred
symbol, and not the other way around, is enough to make life easier for
users of Qt. It's also great if the same symbol renames are done in QML 1
where it makes sense, but again this isn't something that needs to happen
in Qt 5.0.0.

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

Re: [Development] QPixmap::fill( const QWidget *, ... )

[Andreas Aardal Hanssen]

Den 21:10 10. april 2012 skrev Uwe Rathmann uwe.rathm...@tigertal.defølgende:

 On 04/10/2012 08:03 PM, Uwe Rathmann wrote:Unfortunately QWidget::render
 doesn't work. In my use case I'm inside of
 QWidget::paintEvent and using QWidget::render leads to a recursive call
 of QWidget::paintEvent.


You want to take a screenshot of the widget from within the widget's own
paintEvent? That cannot possibly work. Or even if it did, the result would
be completely non-deterministic. The painting code required to take the
screenshot is in the same function.

Why do you want this? :-) Are you writing some fancy blending code that
feeds the widgets' own rendered output back into its painting code?

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

Re: [Development] When to remove old platform plugins?

[Andreas Aardal Hanssen]

2012/3/8 Holger Hans Peter Freyther hol...@freyther.de

 qvfb:
 QWS is dead.. is there any reason to have this around?


QWS isn't removed so please don't remove qvfb. qvfb is used extensively
where I work.


 vnc:
 Currently being removed


That's really really too bad. I use the vnc driver to debug GUI
functionality on hardware that does not yet have display capabilites, and
for remote debugging. It works, please don't remove it.

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

Re: [Development] Changing qreal to a float

[Andreas Aardal Hanssen]

2012/2/21 Thiago Macieira thiago.macie...@intel.com

 On terça-feira, 21 de fevereiro de 2012 09.59.49, Marc Mutz wrote:
  sure I'd like that), then keeping QRect and using QRectI =
 QBasicRectint
  could do the trick.
 QRect must have the same semantics as it has today. Whether we want to add
 a
 *second* rectangle class with slightly different semantics, I'll leave up
 to
 the implementor.


QRect's silly semantics are one huge reason why it can make sense to
obsolete it and its friends, and make new QRectangle classes that all
behave the same.

I've run into numerous issues that are due to the fact that some rectangle
variable's right() value is different depending on whether it's QRect or
QRectF. QRect was kept this way for compatibility with Qt 3. Qt 5 should
have no more such crap.

There never was any QPoly (gon), QEll (ipse), why should there be a QRect.
M'just sayin'.

(sorry if this arrives twice to the list btw)

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

Re: [Development] Use make before you push and stage

[Andreas Aardal Hanssen]

 While that it would be awesome to have a system which could compile test each 
 uploaded patch set, and preferably have the results available before 
 developers would review them, I think it something that will not scale; at 
 least not without a system which can guarantee proper incremental builds 
 (ccache would be a hack, still waste lots of resources, and only works with 
 GCC.)

How about investigating incremental builds? Could reduce compile time to just a 
few minutes per patch. We do that where I work, with hundreds of changes done 
to the repo every day, and every single patch is compiletested. Tests are also 
run per change, but we only run fast tests per change; slow tests are run in a 
separate cycle (on a best effort basis).

The occasional breakage happens whenever changes are made to build files, like 
Makefiles or pro files, typically when moving code around. But it's rare and 
manageable, as long as it's possible to force a full rebuild on demand.

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

Re: [Development] Hacking guide for Qt's SSL Support

[Andreas Aardal Hanssen]

2012/1/1 Richard Moore r...@kde.org

 I've just added a WIP guide to working on the SSL code in Qt. Please
 feel free to edit/extend/comment:

https://wiki.qt-project.org/Hacking_on_Qts_SSL_Support


Hi Richard, looks really good! For Qt 4, the idea was to have several
backends like you write here. Still we ended up with only one, and it's not
really that much of a well-define backend. Especially considering it's the
only one ;-).

The other options I imagined were GnuTLS [*], and using native SSL support
should that exist.

Today the backend separation is still around but it only complicates the
code unless there truly are other backends to support.

What are your thoughts on this?

Andreas

[*] http://www.gnu.org/software/gnutls/ - dropped because it clearly staged
it was in early Alpha stage at the time, which I find to be really scary
for a security framework, and currently I don't think the licensing looks
very interesting. If OpenSSL does the job then why use GnuTLS?

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