Re: [Development] A QtCore class for event-driven jobs

[Konstantin Ritt]

Thanks Marc,

that's exactly what I was saying about. The only difference is (seems to
be) a user-visible "manager" that "owns" (or let's say "locks") the task up
until it gets processed so no deletion may occur in the middle of
execution, i.e.
What the manager is and where/how it executes the tasks is probably up to
the user but having a "standard" interface with some guaranteed
functionality is for good, IMO.

Regards,
Konstantin


2013/9/13 Marc Mutz 

> On 2013-09-12 08:07, André Somers wrote:
> > Op 11-9-2013 17:19, David Faure schreef:
> >>> Couldn't such a class be part of the hopefully coming QtConcurrent
> >>> replacement?
> >> Can we forget about threads for a second?
> > No, I'd rather not forget that huge pink elephant in the room... In
> > this
> > age of multi-core systems being the norm rather than exception, we
> > simply cannot ignore threads when designing a generic API for
> > asynchronous jobs.
> >>
> >> The main point of event-driven jobs is to have them use the event
> >> loop, NOT
> >> threads.
> > That sounds pointless to me. Why would you design an API for
> > asynchronous jobs, but limit that to those jobs that use the eventloop?
> > What does the user of the API really care what the API does to pull of
> > the async-ness? Compare with QNAM: it uses threading too in the
> > background, doesn't it?
> >
> > To me, a generic job API only makes sense if the API makes sense for
> > all
> > async operations, no matter if the job itself uses threading or the
> > eventloop to work. Both should work equally well, and have equal
> > support
> > IMHO.
>
> Seconded.
>
> I, too, have written Job-classes, but I wouldn't do so anymore. That
> concept is so 90's.
>
> I'd use a future. A future isn't (necessarily) the result of a thread.
> It's a placeholder for an asynchronously calculated result. That could
> be a UDP message. And Qt's future can even transport progress, and
> supports cancellation and stop/resume. It's not a QObject, except if you
> want it to (QFutureWatcher). All that's needed is to wrap
> QFutureInterface into a QPromise (and wrap that one into a
> QPackagedTask). And the future needs .then() support.
>
> Thanks,
> Marc
> ___
> 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] More on QDateTime / QTimeZone

[John Layt]

On Thursday 12 Sep 2013 13:48:24 Thiago Macieira wrote:
> On quinta-feira, 12 de setembro de 2013 21:06:03, John Layt wrote:
> > * Choose either local msecs or epoch msecs, if epoch then that change
> > can't
> > be  done for 5.2
> 
> Choose the easiest for you to implement. We're running out of time, so I'd
> rather stick to the implementation you have and your best recommendation.

I've spent the evening writing and running some benchmark tests (amazingly we 
didn't have any before).  Each benchmark creates a date a day for 10 years and 
calls the tested method, so 3650 consecutive dates.  The numbers here are from 
1000 iterations on my i7.  As expected they're a mixed return with some things 
faster and some things slower (not all tests shown):

Action  BaseMsecs %
--  -   -  
create():   0.294   0.39233
isValid():  0.339   0.49245
date(): 0.313   0.632   102
time(): 0.311   0.639   105
timeSpec(): 0.311   0.40330
offsetFromUtc():7.466   9.00921
toMSecsSinceEpoch():6.690   8.83632
toMSecsSinceEpoch1950():7.522   3.642   -52
toMSecsSinceEpoch2050():8.618  10.79025
setDate():  0.418   0.83299
setTime():  0.385   0.820   113
setTimeSpec():  0.340   0.50849
setOffsetFromUtc(): 0.347   0.43826
setMSecsSinceEpoch():   6.020   2.564   -57
addDays():  0.701   1.12961
addMonths():1.836   2.27024
addYears(): 1.826   2.25523
addMSecs():12.820  10.370   -19
toTimeSpec():   6.900   9.24734
toOffsetFromUtc():  7.251   9.29228
daysTo():   0.365   0.953   161
msecsTo(): 13.510  17.78032
equivalent():   0.367   0.43920
equivalentUtc():6.730   9.01834
lessThan(): 0.355   0.44425
lessThanUtc():  6.714   8.90633
currentDateTime():  1.118   0.314   -72
fromMSecsSinceEpoch():  6.094   2.451   -60


* Things that start with an msecs value (i.e. use localtime) are 60-80% faster
* Things that start with a date and time (i.e. use mktime) are 30% slower.
* Focusing on optimising toMSecsSinceEpoch() will cause most other methods to 
speed up, if I remove a tzset call it runs faster than the baseline.
* The getting and setting of the date and time are obviously slower as they 
now involve conversions.
* Rather strangely timeSpec() is 30% slower despite now only returning the 
member directly instead of having to do a switch based on the member, a few 
other calls are equally confusing.

Cheers!

John.

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

Re: [Development] Qt Platform Extras

[Sze Howe Koh]

On 11 September 2013 01:07, Laszlo Papp  wrote:
> On Tue, Sep 10, 2013 at 4:46 PM, Thiago Macieira 
> wrote:
>>
>> On terça-feira, 10 de setembro de 2013 22:31:53, Sze Howe Koh wrote:
>> > On 10 September 2013 14:27, Knoll Lars  wrote:
>> > > Ok, let's use QtWin for the namespace. For the module itself it makes
>> > > IMO
>> > > to keep the 'Extras' in the name.
>> > >
>> > > Cheers,
>> > > Lars
>> >
>> > QtWin or QWin?
>>
>> QtWin, it's a namespace.
>
>
> I believe he is aware of that...
>
> I think, Sze please correct me if I am wrong, he just wanted to make sure
> because there was several emails last year about QFoo or QtFoo for the
> namespace, and it seemed that the suboptimal naming was chosen for other
> reasons.

Laszlo is correct.

Before Qt 5 was released, most public namespaces had the "QFoo" format
-- QSsl, QDBus, QAudio, etc. A few had the "QtFoo format --
QtMultimedia::MetaData (unreleased), QtMultimedia (unreleased), and
QtConcurrent. I suggested making them uniform. [1]

Lars said that he preferred "QFoo" -> "QtFoo", but that change was the
much more intrusive one. Qt 5 was close to Beta 2 at the time, so he
chose the lower-risk "QtFoo" -> "QFoo". [2]

As of Qt 5.1, all public namespaces are "QFoo", except "Qt" and
"QtConcurrent". Thiago blocked the latter on the basis that (i)
development on that module has stopped, and (ii) QtConcurrent is quite
different from all the other namespaces anyway. [3]

With all that in mind, do we want "QtWin" or "QWin"? The benefit of
"QWin" is consistency with existing conventions; the downside is
having to wait till Qt 6 if we want to switch to the preferred
"QtFoo". "QtWin" has the benefit of introducing users to the preferred
naming convention now (and a smaller list of namespace changes if/when
the change occurs), at the cost of introducing more inconsistencies.

I vote for "QWin" for consistency, and I'm not sure that an extra
':%s/QWin::/QtWin::/g' will make a difference to users if they're
doing the same for all other namespaces in Qt 6.


Regards,
Sze-Howe

[1] http://lists.qt-project.org/pipermail/development/2012-October/007421.html
[2] http://lists.qt-project.org/pipermail/development/2012-October/007591.html
[3] https://codereview.qt-project.org/#change,39375
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Validating JSON with schema?

[Leandro T. C. Melo]

On Fri, Sep 13, 2013 at 11:00 PM,  wrote:

> Hello,
>
> I am wondering if there are any plans to support the validation of JSON
> data in Qt using a JSON schema. Qt supports the validation of XML using
> an XML schema with QtXmlPatterns (example:
> http://qt-project.org/doc/qt-4.8/xmlpatterns-schema.html). What is the
> likelihood that we will see similar functionality for JSON in the near
> future?
>


Hi,

in the case you're interested on code, I implemented a partially compliant
JSON validator for Qt Creator a while ago (there's wasn't actually a
standardised specification back then, only the draft - I'm not sure what's
the state now). The code might not be that easily extracted though because
it relied on the QML/JS model components.

Originally this was not a documented feature, but if no one has done work
in the area I'd guess it's still there.

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

Re: [Development] Validating JSON with schema?

[Chris Craig]

There is an example of JSON validation in the qtjsonstream playground
project 
(http://qt.gitorious.org/qtplayground/qtjsonstream
or
on codereview.qt-project.org).  Please keep in mind that this project is
dormant, and the code is almost certainly never going to go into Qt core in
its present state.  But you might find it useful if you are in need of some
code now.

Chris


On Fri, Sep 13, 2013 at 5:00 PM,  wrote:

> Hello,
>
> I am wondering if there are any plans to support the validation of JSON
> data in Qt using a JSON schema. Qt supports the validation of XML using
> an XML schema with QtXmlPatterns (example:
> http://qt-project.org/doc/qt-4.8/xmlpatterns-schema.html). What is the
> likelihood that we will see similar functionality for JSON in the near
> future?
>
> Thanks,
>
> Alfonso
> ___
> 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] Validating JSON with schema?

[achartier]

Hello,

I am wondering if there are any plans to support the validation of JSON
data in Qt using a JSON schema. Qt supports the validation of XML using
an XML schema with QtXmlPatterns (example:
http://qt-project.org/doc/qt-4.8/xmlpatterns-schema.html). What is the
likelihood that we will see similar functionality for JSON in the near
future?

Thanks,

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

Re: [Development] A QtCore class for event-driven jobs

[Marc Mutz]

On 2013-09-12 08:07, André Somers wrote:
> Op 11-9-2013 17:19, David Faure schreef:
>>> Couldn't such a class be part of the hopefully coming QtConcurrent
>>> replacement?
>> Can we forget about threads for a second?
> No, I'd rather not forget that huge pink elephant in the room... In 
> this
> age of multi-core systems being the norm rather than exception, we
> simply cannot ignore threads when designing a generic API for
> asynchronous jobs.
>> 
>> The main point of event-driven jobs is to have them use the event 
>> loop, NOT
>> threads.
> That sounds pointless to me. Why would you design an API for
> asynchronous jobs, but limit that to those jobs that use the eventloop?
> What does the user of the API really care what the API does to pull of
> the async-ness? Compare with QNAM: it uses threading too in the
> background, doesn't it?
> 
> To me, a generic job API only makes sense if the API makes sense for 
> all
> async operations, no matter if the job itself uses threading or the
> eventloop to work. Both should work equally well, and have equal 
> support
> IMHO.

Seconded.

I, too, have written Job-classes, but I wouldn't do so anymore. That 
concept is so 90's.

I'd use a future. A future isn't (necessarily) the result of a thread. 
It's a placeholder for an asynchronously calculated result. That could 
be a UDP message. And Qt's future can even transport progress, and 
supports cancellation and stop/resume. It's not a QObject, except if you 
want it to (QFutureWatcher). All that's needed is to wrap 
QFutureInterface into a QPromise (and wrap that one into a 
QPackagedTask). And the future needs .then() support.

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

[Development] Heads up: QtAlgorithms to be deprecated in 5.2

[Giuseppe D'Angelo]

Hello,

https://codereview.qt-project.org/#change,43441 (currently waiting for a 
review) is going to mark most of the QtAlgorithms functions as deprecated.


The decision about this has already happened some time ago:
http://www.mail-archive.com/development@qt-project.org/msg01603.html

To summarize it up, there are several good reasons to do this, most notably:
- Qt 5 requires STL;
- STL algorithms are far better than ones in Qt;
- Due to the fact that Qt algorithms use qLess and qSwap, it's just not 
possible to reimplement Qt algorithms in terms of the STL counterparts 
and keep 100% compatibility with existing code.


=== Impact for user code ===

- A mere search-and-replace will fix most of the deprecation warnings. 
Probably the most annoying bit is that Qt offers convenience overloads 
taking a container instead of an iterator:


qSort(list); // needs to become: std::sort(list.begin(), list.end())

(If you're reading this and are in the C++ committee, please, you know 
what to propose for the next Standard.)


- If you specialized qLess for your type, you need to pass it 
*explicitly* to the STL algorithm as the comparison functor:


QList list;
std::stable_sort(list.begin(), list.end(), qLess());

- If you specialized qSwap for your type, you need to specialize 
std::swap to make it called by STL:


namespace std {
template<> void swap(Foo &lhs, Foo &rhs) { ... }
}

(Given you're at it, it's an *extremely good idea* to provide move 
operators too. Sorting algorithms will use it in C++11.)


Note that Qt specializes std::swap for you if you use Q_DECLARE_SHARED 
for your type, by requiring you to implement a swap() member function.


- Unlike qSort, std::sort requires the comparison functor to really 
honour Strict Weak Ordering. This means that if comp(a, b) returns true, 
then comp(b, a) *must* return false.


If you start to see crashes inside STL algorithms, please check the 
functor. Common mistakes are:


1) functors returning "true" to express "equivalent" items
2) functors using the relative position of two items (in a list/array) 
as sorting criterion


Example of 1) https://codereview.qt-project.org/65408
Example of 2) https://codereview.qt-project.org/65015

This also means that if the comparison functor is somehow "user 
provided" and you can't trust that it's really enforcing SWO, then you 
should stay with Qt algorithms (or maybe write one yourself), as the 
Standard says that it's a requirement violation, leading to undefined 
behaviour.


- C++03 has a broken wording about algorithms such as lower_bound / 
upper_bound: in spite of them having two overloads (one with and one 
without a comparison functor), §25.3.3.1.1 [lower.bound] for instance says:


Requires: Type T is LessThanComparable (20.1.2).

I.e. operator<(T, T) must exist. The pitfall is that we're allowed to 
pass a value of type V != T as the value to look for, and a functor with 
signature


bool f(T, V)

to perform the search. This means that operator<(T, T) might not exist 
at all.


Some C++03 compilers (hello, MSVC 2008), when in debug mode, use the 
requirement to ease development by checking if the iterator range is 
indeed sorted by operator<(T, T). Unfortunately, if the operator doesn't 
exist, compilation fails (!). Adding a operator< fixes the issue. 
(Probably even a dummy one, which always returns false I'm 
not recommending it).


https://bugreports.qt-project.org/browse/QTBUG-33473 is tracking this 
for qtbase itself.


(The wording has been corrected in C++11, cf. §25.4.3.1.1).

===

Comments?

--
Join us at Qt Developer Days 2013! - https://devdays.kdab.com
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt WebEngine

[Alexis Menard]

On Fri, Sep 13, 2013 at 2:03 PM, Jiang Jiang  wrote:

> On Fri, Sep 13, 2013 at 1:39 PM, Alexis Menard  wrote:
>
>> Qt integration will be on top of the Content Shell and this single
>> process mode needs to work because Google needs it for their Android
>> WebView.
>>
>
> Alexis, I think you meant "Content API"  here, not Content Shell, right?
>

Yes sorry, my bad. I meant the Content API.


>
> I didn't work on Android (I now work for Opera on the Mac platform
> mostly), and not quite familiar with the single process support status, but
> I have heard it getting broken from time to time and usually being used as
> a test / diagnose tool, instead of officially supported as a process model.
> (In Opera for instance we try not to break single process mode but no one
> is really actively developing for it or count on it.) Maybe it worked well
> enough for content module? Do you have any further information about that?
> (Proving that Qt WebEngine can safely use single process mode on platforms
> that requires it.)
>

Well talking with the people working on the Android WebView they decided to
opt for the single process approach so at least up until the content API it
needs to work. I'm not involved in the WebView work but you should clarify
with them.


>
> - Jiang
>
>


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

Re: [Development] Qt WebEngine

[Jiang Jiang]

On Fri, Sep 13, 2013 at 1:39 PM, Alexis Menard  wrote:

> Qt integration will be on top of the Content Shell and this single process
> mode needs to work because Google needs it for their Android WebView.
>

Alexis, I think you meant "Content API"  here, not Content Shell, right?

I didn't work on Android (I now work for Opera on the Mac platform mostly),
and not quite familiar with the single process support status, but I have
heard it getting broken from time to time and usually being used as a test
/ diagnose tool, instead of officially supported as a process model. (In
Opera for instance we try not to break single process mode but no one is
really actively developing for it or count on it.) Maybe it worked well
enough for content module? Do you have any further information about that?
(Proving that Qt WebEngine can safely use single process mode on platforms
that requires it.)

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

Re: [Development] Pointer aliasing problem in optimized gcc builds

[Konstantin Tokarev]

13.09.2013, 19:51, "Thiago Macieira" :
> On sexta-feira, 13 de setembro de 2013 17:22:32, Olivier Goffart wrote:
>
>>>  * How bad are -O3 compiles? I've read that it's completely safe for
>>>  well-written code but using optimization aggressively, may cause undefined
>>>  behavior or even runtime crashes for bad codes. How is Qt code?
>
> I've only used -O3 for my optimised builds for 6 years. In fact, I only run Qt
> 4 with -O3 nowadays, except when I need to debug something.

Strict aliasing is enabled at -O2 as well.

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

Re: [Development] Pointer aliasing problem in optimized gcc builds

[Thiago Macieira]

On sexta-feira, 13 de setembro de 2013 20:13:30, Konstantin Tokarev wrote:
> 13.09.2013, 19:51, "Thiago Macieira" :
> > On sexta-feira, 13 de setembro de 2013 17:22:32, Olivier Goffart wrote:
> >>>  * How bad are -O3 compiles? I've read that it's completely safe for
> >>>  well-written code but using optimization aggressively, may cause
> >>> undefined
> >>>  behavior or even runtime crashes for bad codes. How is Qt code?
> > 
> > I've only used -O3 for my optimised builds for 6 years. In fact, I only
> > run Qt 4 with -O3 nowadays, except when I need to debug something.
> 
> Strict aliasing is enabled at -O2 as well.

There are no known aliasing violations in Qt, outside of qtdeclarative.

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


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pointer aliasing problem in optimized gcc builds

[Olivier Goffart]

On Friday 13 September 2013 15:55:45 Soroush Rabiei wrote:
> Hi everybody
> 
> 
> I'm using a custom build of Qt 5.1.1 compiled with GCC 4.8.1 on
> Windows (MinGW builds x86_64). For some performance reasons I have to
> enable "-O3" flag until my project is ported out of Qt. The Qt was
> built with C++11 support.
> 
> 
> When program tries to append an item to a container it crashes.
> Debuggers stops at this line in qlist.h:
> 
> 
> template 
> 
> Q_OUTOFLINE_TEMPLATE void QList::append(const T &t)
> 
> {
> 
> if (d->ref.isShared()) { // <== Here
> 
> Node *n = detach_helper_grow(INT_MAX, 1);
> 
> QT_TRY {
> 
> node_construct(n, t);
> 
> } QT_CATCH(...) {
> 
> --d->end;
> 
> QT_RETHROW;
> 
> }
> 
> // ...
> 
> 
> Looking into functions that append calls, I found that node_construct
> contains some unsafe code:
> 
> 
> template 
> 
> Q_INLINE_TEMPLATE void QList::node_construct(Node *n, const T &t)
> 
> {
> 
> if (QTypeInfo::isLarge || QTypeInfo::isStatic) n->v = new T(t);
> 
> else if (QTypeInfo::isComplex) new (n) T(t);
> 
> #if (defined(__GNUC__) || defined(__INTEL_COMPILER) ||
> defined(__IBMCPP__)) && !defined(__OPTIMIZE__)
> 
> // This violates pointer aliasing rules, but it is known to be
> safe (and silent)
> 
> // in unoptimized GCC builds (-fno-strict-aliasing). The other
> compilers which
> 
> // set the same define are assumed to be safe.
> 
> else *reinterpret_cast(n) = t;
> 
> #else
> 
> // This is always safe, but penaltizes unoptimized builds a lot.
> 
> else ::memcpy(n, static_cast(&t), sizeof(T));
> 
> #endif
> 
> }
> 
> 
> I guess problem is same in detach_helper_grow function. Tried adding
> -fno-strict-aliasing to compile flags and defined __OPTIMIZE__. Also
> removed -O3 from compile flags, but no hope. So I have a couple of
> questions:
> * How bad are -O3 compiles? I've read that it's completely safe for
> well-written code but using optimization aggressively, may cause undefined
> behavior or even runtime crashes for bad codes. How is Qt code?
> * How can I solve this problem? (Using official builds is not preferred)
> * Do I need to recompile Qt with "-fno-strict-aliasing" flag or defining
> __OPTIMIZE__ ? Since templated classes are header-only and I already tried
> both in my project, I guess the answer is no.


Hi,

It is much more likely that the problem is somewhere else in your program.
Especially if you can reproduce the problem without optimisation.

I bet you have a dangling pointer somewhere in your application.

The reinterpret_cast there should be safe as the node are only accessed as T.

(memcpy is builtin, even in debug mode so the comment is wrong and the code 
could be simplified)

-- 
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

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

Re: [Development] Pointer aliasing problem in optimized gcc builds

[Thiago Macieira]

On sexta-feira, 13 de setembro de 2013 17:22:32, Olivier Goffart wrote:
> > * How bad are -O3 compiles? I've read that it's completely safe for
> > well-written code but using optimization aggressively, may cause undefined
> > behavior or even runtime crashes for bad codes. How is Qt code?

I've only used -O3 for my optimised builds for 6 years. In fact, I only run Qt 
4 with -O3 nowadays, except when I need to debug something.

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


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Binary incompatible change in dev branch.

[Stephen Kelly]

Hello,

Two changes which are binary incompatible compared to the state before them 
were just merged to dev:

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

The changes are to APIs which were not present in Qt 5.1. 

This is a heads-up that you may need to re-build everything the next time you 
update your qtbase repo. 

Thanks,

-- 
Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com

Stephen Kelly  | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] More on QDateTime / QTimeZone

[John Layt]

On Thursday 12 Sep 2013 22:24:40 Robin Burchell wrote:
> On Thu, Sep 12, 2013 at 9:24 PM, Knoll Lars  wrote:
> > We might be able to simply cache the time zone offset once and cache it.
> > Then it should be at the same speed.
> 
> This would also probably provide hidden wins in various places, making
> changes like b9ef4a9c3047228ec007ac81ff0a304f8cc274b7 in qtbase
> unnecessary. I'd like to see this for that reason :)

Well, that patch is taking advantage of the fact that creating a LocalTime is 
currently cheap, as is calling setTimeZone, neither of those steps currently 
require a conversion to UTC.  As explained in my reply to Lars with any change 
in storage you would always have to call mktime in the creation, so you 
immediately lose the speed-up from your patch.  There's probably a lot of 
places this will happen in Qt, not to mention other people's code.  There's no 
such thing as a free lunch :-)

The real problem is that the file code uses LocalTime internally when it should 
use UTC and only convert to LocalTime as the last step in the public api.  My 
understanding is Unix stores file times as time_t, and Windows as a FILETIME 
which is nsecs since 1601, both are UTC, so at the moment there is already a 
conversion from UTC to LocalTime required to create the LocalTime.  Creating 
and passing them around internally as UTC could be a big saving, however I 
suspect that would take a large change to achieve.

John.

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

Re: [Development] More on QDateTime / QTimeZone

[John Layt]

On Thursday 12 Sep 2013 19:24:15 Knoll Lars wrote:
> On 9/12/13 9:06 PM, "John Layt"  wrote:
> >The first is it means creating a QDateTime becomes a
> >lot slower as we need to calculate the epoch offset up-front, instead of
> >only when/if needed.
> 
> We might be able to simply cache the time zone offset once and cache it.
> Then it should be at the same speed.

No, because we don't know the rules for when to apply Daylight Time, that's 
why we'd need to call mktime for every new datetime creation.  It can't be 
avoided.

Besides, we already have a spec that offers this style behaviour: OffsetFromUTC.

> >The second is it means that the behaviour of the local
> >date/time staying constant over time zone changes will no longer be true.
> > It would be up to the app to realise a time zone change has happened and
> >to know what to do with the datetimes as a result.
> 
> Well, IMO that's in most cases what you'd want in any case. I can't see
> how a date time specifying 5pm for a meeting should stay at 5pm when I fly
> to finland...

You also don't say I want an appointment at 2pm UTC whatever that happens to 
be in local time, if you do and the daylight conversion rules change your 
local appointment time also ends up changing.  You instead say I want an 
appointment at 3pm local time *in Oslo*.  You only convert that to UTC if you 
need to see what that local time is in another tz.  QTimeZone will give us a 
proper way to do that.  You'd be crazy to currently be using LocalTime for 
such things, you'd use UTC or OffsetFromUTC or KDateTime instead.

Where the local date/time stays constant is what's normally known as Clock 
Time or Wall Time, i.e. I want to wake up at 7am no matter where in the world 
I am.  That's what LocalTime is closest to.  If we switched LocalTime then 
we'd need to add a new spec for ClockTime/WallTime/SystemTime to replicate 
that behaviour.

The problem with LocalTime is it's neither fish nor fowl, it's just "This local 
time, if you want UTC just use whatever the system time zone currently is".  
We don't know what the most common use case is, but I suspect it's getting the 
current local time, and showing a local date as a string.  Most other use 
cases will revolve around "whatever the current system tz is", or even not 
care at all.  It's the local time value they mostly want, not the UTC 
equivalent.

The biggest problem I see with switching the behaviour is to define how to 
update a datetime if needed after a time zone change.  If we cache whatever 
offset mktime returns at QDateTime creation, then when the tz changes any new 
dates will immediately be created with the new offset, but the old instances 
will still have the old offset, leaving things inconsistent and still not under 
the apps control.  You would also then need api for the app to tell the old 
instances to update to the new offset, which seems ugly and inefficient and 
prone 
to failure.  The alternative is to use a cached QTimeZone to look up the offset 
every time, that way the offset remains consistent until the app chooses to 
refresh the cached QTimeZone, but then you lose any efficiency gains and you 
might as well keep the old behaviour for now.

We also need to think about the serialization behaviour: do we still serialize 
as the local time as we currently do, or as the UTC time?  And how does that 
affect serializing a time expressed in a QTimeZone?  Is it a time in UTC to be 
interpreted into a given tz, or is it a given local time to be interpreted 
into UTC?  If I make an appointment for 3pm Oslo time then I want that to stay 
in Oslo time regardless if the rules for conversion to UTC change between 
serialize/deserialize, so that still needs to serialize as local.

We'd also need to think about de-serializing old formats and how to convert 
them correctly.

We may not need to implement all this in the first cut, but we at least need to 
think about how it will work, otherwise we could end up releasing something 
half-way there and then finding we can't actually make it work in teh full 
solution.

If we do make the change, I'd also rather do it in a different way.  Keep the 
LocalTime spec behaving as it does so legacy code can easily switch to using 
it, but create a new spec called something like SystemTime that behaves the 
way you want, then possibly change the default spec from LocalTime to 
SystemTime.

> Wouldn't the issues here be solved by storing all time values in UTC? In
> any case, I don't believe this is a showstopper for 5.2.

No, because you still need to make that initial conversion from local time to 
UTC using mktime, so you'll still get the same inconsistencies.  But yes, it's 
a problem for later.

> These are corner cases (as the OSes don't really solve them as well
> apparently). I'd not worry too much about this for 5.2. If we get this
> settled in 5.3 it's good enough.

Corner cases, yes, thankfully most people don't schedule appointments for 2am 
in the morning of dayli

Re: [Development] Qt WebEngine

[Alexis Menard]

Hi,


On Fri, Sep 13, 2013 at 7:06 AM, Konstantin Tokarev wrote:

>
>
> 12.09.2013, 16:04, "Knoll Lars" :
> > Hi,
> >
> > As many of you know, we've been doing some research on a (chromium based)
> > new web engine for Qt during spring and summer. I wanted to let you know
> > that we've now come to the conclusion that we want to continue these
> > efforts in the future.
> >
> > Please check
> > http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/for
> > all the details.
>
> IMHO, this is a really bad decision. WebKit is a meritocracy-driven
> community project with many large and small contributors, while Chromium
> seems to be driven solely by Google employees. If Google needs to do some
> ground-breaking changes in the engine, they will do it, and don't hope they
> to care about 3rd party products being broken.
>


This is simply not true. Samsung, Intel, Adobe, Opera have been able to
contribute a lot and influence the development in many ways since the fork
date. I speak of experience. Adobe, Intel and Samsung already have
reviewers (Owners).

The problem of breaking was also happening in WebKit, for example Apple
removed the support of Windows for WebKit2 letting QtWebKit alone broken if
Digia didn't help.


>
> >Chromium has a cross-platform focus, with the browser being available on
> all major desktop platforms and Android. The same is no longer true of
> WebKit, and we would have had to support all the OS’es on our own in that
> project.
>
> To run QtWebKit on embedded platform with unsupported native graphics API,
> it's enough to write gfxdriver for Qt 4, or QPA plugin for Qt 5. Basically,
> if Qt works, QtWebKit works too. To run Chromium I will also need to port
> Skia, and maybe other things. IIRC, it does not even support DirectFB out
> of the box.
>

Yes that's one of the things that needs investigation. But in that
particular case of custom hardware with custom graphics driver on a custom
OS I believe QtWebKit is not best suited. Maybe you want to look at the Nix
port of WebKit which is a low level WebKit port requiring Cairo and OpenGL
to run : http://nix.openbossa.org/


>
> >There are many things that are available out-of-the box from Chromium,
> which would require a lot of work for us to support ourselves in WebKit.
> One example, is the whole platform/OS adaptation that we can simply re-use.
> Multimedia and new HTML5 features such as WebRTC are working out-of the-box
> and don’t require any Qt-specific code.
>
> This implies larger size of binaries for embedded users because of massive
> duplication between Qt and Chromium cross-platfrom layers.
>


Yes but given the small amount of resources one needs to be pragmatic.
Maintaining, releasing, updating a web engine is a very resource demanding
task (and full time) and clearly the Qt project doesn't have the bandwidth
to do so. Therefore it needs to seek for alternatives and help. What is
better? A QtWebKit broken, outdated, unsecure or state-of-art engine (with
maybe slightly less capabilities)? Or maybe just nothing?


>
> >As using Chromium simplifies handling the OS integration, this allows us
> to spend additional time to focus on the upper layers to provide a great
> and easy-to-use API and a seamless integration into Qt as possible.
>
> Does Chromium provide any C++ API warranties? You may end up overhaul your
> fancy integration layer each time you update.
>

You can build on top of the Content Shell module which is what Google is
using to build Chrome, what they use to build their Android WebView and
what Opera uses to build their browser. Crosswalk is also based on top of
that.


>
> >We are seeing that Chromium is being developed with very strict control
> on quality.
>
> WebKit also has solid testing infrastructure.
>

The one of Chromium is the one of WebKit basically even improved. Every
patch is tested (with LayoutTests) on Windows, Mac, Linux which is not the
case in WebKit (it was only running with the Chromium port on Linux only
and now run only on Mac OS). The QA team of Google is magnitude bigger than
what QtWebKit had and the quality of the releases of Chromium proves it.
Not to mention the amount of bots running the code in so many different
configurations.

Google has a dedicated security team working on Chromium, QtWebKit never
had that (and all the fixes are not just in core code, but can be in port
specific code).


>
> >Finally, we are seeing that Chromium is currently by far the most dynamic
> and fastest moving browser available
>
> WebKit is moving slower because it has to care about all its ports. All
> significant architecture changes are discussed by community. Chromium is
> fast because they don't care about anyone else.
>

Again a bold statement of somebody who has not participated to the projects.

Before Google forked they were #1 in the project in term of contributions,
many of CSS/HTML features were developed by them. Of course when they
forked then the number of features in dev

[Development] Pointer aliasing problem in optimized gcc builds

[Soroush Rabiei]

Hi everybody


I'm using a custom build of Qt 5.1.1 compiled with GCC 4.8.1 on
Windows (MinGW builds x86_64). For some performance reasons I have to
enable "-O3" flag until my project is ported out of Qt. The Qt was
built with C++11 support.


When program tries to append an item to a container it crashes.
Debuggers stops at this line in qlist.h:


template 

Q_OUTOFLINE_TEMPLATE void QList::append(const T &t)

{

if (d->ref.isShared()) { // <== Here

Node *n = detach_helper_grow(INT_MAX, 1);

QT_TRY {

node_construct(n, t);

} QT_CATCH(...) {

--d->end;

QT_RETHROW;

}

// ...


Looking into functions that append calls, I found that node_construct
contains some unsafe code:


template 

Q_INLINE_TEMPLATE void QList::node_construct(Node *n, const T &t)

{

if (QTypeInfo::isLarge || QTypeInfo::isStatic) n->v = new T(t);

else if (QTypeInfo::isComplex) new (n) T(t);

#if (defined(__GNUC__) || defined(__INTEL_COMPILER) ||
defined(__IBMCPP__)) && !defined(__OPTIMIZE__)

// This violates pointer aliasing rules, but it is known to be
safe (and silent)

// in unoptimized GCC builds (-fno-strict-aliasing). The other
compilers which

// set the same define are assumed to be safe.

else *reinterpret_cast(n) = t;

#else

// This is always safe, but penaltizes unoptimized builds a lot.

else ::memcpy(n, static_cast(&t), sizeof(T));

#endif

}


I guess problem is same in detach_helper_grow function. Tried adding
-fno-strict-aliasing to compile flags and defined __OPTIMIZE__. Also
removed -O3 from compile flags, but no hope. So I have a couple of
questions:
* How bad are -O3 compiles? I've read that it's completely safe for
well-written code but using optimization aggressively, may cause undefined
behavior or even runtime crashes for bad codes. How is Qt code?
* How can I solve this problem? (Using official builds is not preferred)
* Do I need to recompile Qt with "-fno-strict-aliasing" flag or defining
__OPTIMIZE__ ? Since templated classes are header-only and I already tried
both in my project, I guess the answer is no.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt WebEngine

[Konstantin Tokarev]

12.09.2013, 16:04, "Knoll Lars" :
> Hi,
>
> As many of you know, we've been doing some research on a (chromium based)
> new web engine for Qt during spring and summer. I wanted to let you know
> that we've now come to the conclusion that we want to continue these
> efforts in the future.
>
> Please check
> http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/ for
> all the details.

IMHO, this is a really bad decision. WebKit is a meritocracy-driven community 
project with many large and small contributors, while Chromium seems to be 
driven solely by Google employees. If Google needs to do some ground-breaking 
changes in the engine, they will do it, and don't hope they to care about 3rd 
party products being broken.

>Chromium has a cross-platform focus, with the browser being available on all 
>major desktop platforms and Android. The same is no longer true of WebKit, and 
>we would have had to support all the OS’es on our own in that project.

To run QtWebKit on embedded platform with unsupported native graphics API, it's 
enough to write gfxdriver for Qt 4, or QPA plugin for Qt 5. Basically, if Qt 
works, QtWebKit works too. To run Chromium I will also need to port Skia, and 
maybe other things. IIRC, it does not even support DirectFB out of the box.

>There are many things that are available out-of-the box from Chromium, which 
>would require a lot of work for us to support ourselves in WebKit. One 
>example, is the whole platform/OS adaptation that we can simply re-use. 
>Multimedia and new HTML5 features such as WebRTC are working out-of the-box 
>and don’t require any Qt-specific code.

This implies larger size of binaries for embedded users because of massive 
duplication between Qt and Chromium cross-platfrom layers.

>As using Chromium simplifies handling the OS integration, this allows us to 
>spend additional time to focus on the upper layers to provide a great and 
>easy-to-use API and a seamless integration into Qt as possible.

Does Chromium provide any C++ API warranties? You may end up overhaul your 
fancy integration layer each time you update.

>We are seeing that Chromium is being developed with very strict control on 
>quality.

WebKit also has solid testing infrastructure.

>Finally, we are seeing that Chromium is currently by far the most dynamic and 
>fastest moving browser available

WebKit is moving slower because it has to care about all its ports. All 
significant architecture changes are discussed by community. Chromium is fast 
because they don't care about anyone else.

>One of the fundamentals of Chromium is that all rendering of Web content 
>happens in a different process for security and stability reasons.

WebKit 2 multiprocessing model is much better designed and provides stable API. 
Also, single process mode of Chromium in unofficial and often breaks (and it's 
usually worthless to be multi-process on single-core embedded CPU).


I hope there will be some folks to keep maintaining Qt port in WebKit upstream. 
Otherwise, NIX port looks like a good alternative, though it requires 
OpenGL-capable hardware.

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

Re: [Development] QT4.8.5 issue: multi-touch message cannot handled by "close" button

[Duan Fugang-B38611]

From: Rutledge Shawn 
Data: Friday, September 13, 2013 4:11 PM

> To: development@qt-project.org
> Subject: [Development] QT4.8.5 issue: multi-touch message cannot handled
> by "close" button
> 
> On 13 Sep 2013, at 9:44 AM, Duan Fugang-B38611 wrote:
> > The KDE is not kwin, is matchbox-window-manager.
> 
> OK I can reproduce it, so it seems to be an issue with matchbox (and
> matchbox is not using Qt).  But it was designed for PDAs, so maybe there
> is a solution.  The touch drivers for Linux PDAs back then (iPaq, Zaurus,
> Agenda etc.) only provided mouse events, because XInput didn't have touch
> until recently, and anyway a resistive touchscreen is just like a single-
> button mouse.  But the evdev driver should be making your multi-touch
> screen emulate a mouse too, so then I wonder what matchbox is doing so
> that it doesn't work.  Maybe it has been partially updated to support
> touch but doesn't do it correctly?  But you can google and/or find a
> matchbox mailing list or forum to ask about that, or look at the source
> and see if it uses xinput or just the conventional old X11 mouse events.

The current Linux egalax driver locates: drivers/input/touchscreen/egalax_ts.c 
(you can get it from Linux-next git)
When I disable multitouch in the egalax driver to let it work on single touch 
mode, the window of QT apps can be closed by clicked window "X" button at 
up-right region.

The single touch mode report "BTN_TOUCH" event comparing with multi-touch.
How to explain it ?


Thanks,
Andy

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

[Development] QT4.8.5 issue: multi-touch message cannot handled by "close" button

[Rutledge Shawn]

On 13 Sep 2013, at 9:44 AM, Duan Fugang-B38611 wrote:
> The KDE is not kwin, is matchbox-window-manager.

OK I can reproduce it, so it seems to be an issue with matchbox (and matchbox 
is not using Qt).  But it was designed for PDAs, so maybe there is a solution.  
The touch drivers for Linux PDAs back then (iPaq, Zaurus, Agenda etc.) only 
provided mouse events, because XInput didn't have touch until recently, and 
anyway a resistive touchscreen is just like a single-button mouse.  But the 
evdev driver should be making your multi-touch screen emulate a mouse too, so 
then I wonder what matchbox is doing so that it doesn't work.  Maybe it has 
been partially updated to support touch but doesn't do it correctly?  But you 
can google and/or find a matchbox mailing list or forum to ask about that, or 
look at the source and see if it uses xinput or just the conventional old X11 
mouse events.

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

Re: [Development] New SceneGraph related issue

[Sletta Gunnar]

Ok, that stack trace doesn't tell me much as the interesting parameters are 
optimized out :/

If this was a general bug, I suspect the issue would be present in a lot of 
places though, so my immediate reaction is to point towards the emulator :) You 
can compare the buffer size used in uploadBatches() to the offsets and sizes 
used in the renderMergedBatch() function, but from what I can see, they are all 
correct.

There is no way to disable optimizations or use the old renderer. The new logic 
is here to stay.

cheers,
Gunnar


Fra: Tomasz Olszak [olszak.tom...@gmail.com]
Sendt: 12. september 2013 18:53
To: Sletta Gunnar
Cc: development@qt-project.org
Emne: Re: [Development] New SceneGraph related issue

I got stracktrace. It is as you predicted glDrwaElements. Is there any 
possibility to make some kind of workaround patch to make it work on emulator 
(I suppose it is emulator GL issue), perhabs by turning off some optimizations 
and so on? I would like to add such patch to rpm emulator package until problem 
will be fixed.

#0  0xb7fe1424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb69a0cc1 in raise () from /lib/libc.so.6
No symbol table info available.
#2  0xb69a40ee in abort () from /lib/libc.so.6
No symbol table info available.
#3  0xb6999888 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#4  0xb4866d2c in glGetBufferSubDataARB () from /usr/lib/host-gl/libGL.so.1.2
No symbol table info available.
#5  0xb4866d62 in glGetBufferSubData () from /usr/lib/host-gl/libGL.so.1.2
No symbol table info available.
#6  0xb6c20dec in glDrawElements () from /usr/lib/libGLESv2.so.1
No symbol table info available.
#7  0xb7cc3096 in QSGBatchRenderer::Renderer::renderMergedBatch (
this=0x84e6800, batch=0x84e8100)
at scenegraph/coreapi/qsgbatchrenderer.cpp:1863
draw = 
offset = 
i = 
e = 
__PRETTY_FUNCTION__ = "void 
QSGBatchRenderer::Renderer::renderMergedBatch(const QSGBatchRenderer::Batch*)"
---Type  to continue, or q  to quit---
sms = 0x84e5420
g = 0x84e7bbc
attrNames = 
gn = 0xb7fc2e5c
material = 
program = 
#8  0xb7cc4e3f in QSGBatchRenderer::Renderer::renderBatches (this=0x84e6800)
at scenegraph/coreapi/qsgbatchrenderer.cpp:2008
b = 
i = 
__PRETTY_FUNCTION__ = "void QSGBatchRenderer::Renderer::renderBatches()"
renderOpaque = 
renderAlpha = true
#9  0xb7cc6718 in QSGBatchRenderer::Renderer::render (this=0x84e6800)
at scenegraph/coreapi/qsgbatchrenderer.cpp:2168
__PRETTY_FUNCTION__ = "virtual void 
QSGBatchRenderer::Renderer::render()"
#10 0xb7cd5e10 in QSGRenderer::renderScene (this=0x84e6800, bindable=...)
at scenegraph/coreapi/qsgrenderer.cpp:274
profileFrames = 
bindTime = 0
renderTime = 0
---Type  to continue, or q  to quit---
__PRETTY_FUNCTION__ = "void QSGRenderer::renderScene(const 
QSGBindable&)"
#11 0xb7cd60dd in QSGRenderer::renderScene (this=0x84e6800)
at scenegraph/coreapi/qsgrenderer.cpp:231
b = warning: RTTI symbol not found for class 
'QSGRenderer::renderScene()::B'
{ = {
_vptr.QSGBindable = 0xb7fb4240}, }
#12 0xb7ce7e4c in QSGContext::renderNextFrame (this=0x845d620,
renderer=0x84e6800, fboId=0) at scenegraph/qsgcontext.cpp:367
No locals.
#13 0xb7d3273e in QQuickWindowPrivate::renderSceneGraph (this=0x848c870,
size=...) at items/qquickwindow.cpp:358
_qml_memory_scope = {pushed = false}
q = 0x845dc30
fboId = 0
devicePixelRatio = 
#14 0xb7d0bb04 in QSGGuiThreadRenderLoop::renderWindow (this=0x8498128,
window=0x845dc30) at scenegraph/qsgrenderloop.cpp:288
data = @0x8489ba4
current = 
alsoSwap = true
cd = 0x848c870
renderTime = 0
swapTime = 
---Type  to continue, or q  to quit---
__PRETTY_FUNCTION__ = "void 
QSGGuiThreadRenderLoop::renderWindow(QQuickWindow*)"
syncTime = 0
renderTimer = {t1 = -4611697219702095867, t2 = 55969188728}
profileFrames = false
#15 0xb7d0c4ee in QSGGuiThreadRenderLoop::exposureChanged (this=0x8498128,
window=0x845dc30) at scenegraph/qsgrenderloop.cpp:335
No locals.
#16 0xb7d319be in QQuickWindow::exposeEvent (this=0x845dc30)
at items/qquickwindow.cpp:214
d = 
#17 0xb71f6b94 in QWindow::event(QEvent*) () from /usr/lib/libQt5Gui.so.5
No symbol table info available.
#18 0xb7d3dcb4 in QQuickWindow::event (this=0x845dc30, e=0xb880)
at items/qquickwindow.cpp:1241
d = 
#19 0xb6ec782a in QCoreApplicationPrivate::notify_helper (this=0x8055458,
receiver=0x845dc30, event=0xb880) at kernel/qcoreapplication.cpp:986
No locals.
#20 0xb6ec78cb in QCoreApplication::notify (this=0xbc80,
receiver=0x845dc30, event=0xb880) at kernel/qcoreapplication.cpp:931
d = 0x8055458
__PRETTY_FUNCTION__ = "virtual bool QCoreApplication::n

Re: [Development] QT4.8.5 issue: multi-touch message cannot handled by "close" button

[Duan Fugang-B38611]

From: Rutledge Shawn 
Data: Friday, September 13, 2013 2:48 PM

> To: development@qt-project.org
> Subject: Re: [Development] QT4.8.5 issue: multi-touch message cannot
> handled by "close" button
> Importance: High
> 
> 
> On 13 Sep 2013, at 7:53 AM, Duan Fugang-B38611 wrote:
> 
> > Hi, all,
> >
> > We use the X.Org X Server 1.14.0 + QT4.8.5 to do one demo, but I  catch
> one issue: multi-touch message is not handled by "close" button.
> >
> > I use egalax touchscreen for the multi-touch test.
> > After kernel up, evtest test the multi-touch message, all pass. Use
> xinput to do the test, also pass.
> >
> > Open one QT app, all multi-touch message can be processed, but the
> window of the app cannot be closed by click the "X" in the right-up region.
> > I test GNOME destop with the same kernel,  any apps' window can be
> closed.
> >
> > So, It is strange, maybe it is KDE issue for multi-touch ?
> > Any response is appreciative.
> 
> This X button is the one provided by the window manager, right?  
> If you
> are running KDE then it must be kwin.  (Which is probably still using Qt 4)

The KDE is not kwin, is matchbox-window-manager.

> But it probably relies on mouse emulation at some level to detect pressing
> that button.  Maybe the egalax driver or the X server does it, so that any
> legacy X11 apps will work.  (You can try really old X apps that definitely
> don't support touch, like xman, xmessage etc.)  If you have a widget-based
> application with a QPushButton, or a qml application with a MouseArea, can
> you press those via the touchscreen?  because they also need to get mouse
> events rather than touch events (so far).
> 
> Which driver is the X server using for the touchscreen?  (check
> /var/log/Xorg.0.log) ___

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

Re: [Development] QT4.8.5 issue: multi-touch message cannot handled by "close" button

[Duan Fugang-B38611]

From: Rutledge Shawn 
Data: Friday, September 13, 2013 2:48 PM

> > We use the X.Org X Server 1.14.0 + QT4.8.5 to do one demo, but I  catch
> one issue: multi-touch message is not handled by "close" button.
> >
> > I use egalax touchscreen for the multi-touch test.
> > After kernel up, evtest test the multi-touch message, all pass. Use
> xinput to do the test, also pass.
> >
> > Open one QT app, all multi-touch message can be processed, but the
> window of the app cannot be closed by click the "X" in the right-up region.
> > I test GNOME destop with the same kernel,  any apps' window can be
> closed.
> >
> > So, It is strange, maybe it is KDE issue for multi-touch ?
> > Any response is appreciative.
> 
> This X button is the one provided by the window manager, right?
Yes, I think any QT app windows are managed by window manager.

> If you
> are running KDE then it must be kwin.  (Which is probably still using Qt 4)
> But it probably relies on mouse emulation at some level to detect pressing
> that button. 
>From Xorg.0.log: [360470.340] (II) evdev: eGalax Touch Screen: No buttons 
>found, faking one.
The Linux egalax driver don't report button event. Close window of apps need " 
BTN_TOUCH" event ?

The current egalax driver support multitouch events:
root@ /# mtdev-test /dev/input/event0
supported mt events:
   ABS_MT_TOUCH_MAJOR
   ABS_MT_WIDTH_MAJOR
   ABS_MT_POSITION_X
   ABS_MT_POSITION_Y
   ABS_MT_TRACKING_ID
 

> Maybe the egalax driver or the X server does it, so that any
> legacy X11 apps will work.  (You can try really old X apps that definitely
> don't support touch, like xman, xmessage etc.)  If you have a widget-based
> application with a QPushButton, or a qml application with a MouseArea, can
> you press those via the touchscreen?  because they also need to get mouse
> events rather than touch events (so far).
> 
> Which driver is the X server using for the touchscreen?  (check
> /var/log/Xorg.0.log) ___

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

Re: [Development] QT4.8.5 issue: multi-touch message cannot handled by "close" button

[Duan Fugang-B38611]

From: Rutledge Shawn 
Data: Friday, September 13, 2013 2:48 PM

> Which driver is the X server using for the touchscreen?  (check
> /var/log/Xorg.0.log) ___

Shawn, thanks for your response.

I have attached the Xorg log. 

Thanks,
Andy


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