Re: [Development] QtSingleApplication in Qt proper?

2016-06-20 Thread Thiago Macieira 
On terça-feira, 21 de junho de 2016 01:17:07 PDT André Pönitz wrote:
> > I'd like to see KUniqueApplication deprecated, as it relies on some
> > undocumented and fragile QtDBus functionality (namely, connecting to
> > the bus before QCoreApplication is created).
> 
> That's a reason that I have missed so far, but to be honest, I don't
> find it convincing.
> 
> There's surely a way on the Qt side to overcome the "undocumented" part
> of the issue, and the "fragile ... before QCoreApplication is created"
> problem is a bit more generic than DBus-only, and, if taken seriously,
> might warrant a more generic solution than "incorporate some code to
> appease the worst offender".

It's the whole problem of delivering events before and after 
QCoreApplication's lifetime. The event dispatcher checks if QCoreApplication 
exists and, if not, drops all events on the floor[*]. That's required so that 
the event filter can work.

I solved this for Qt 5.6 by creating QDaemonThread, which has no such 
limitation and does not filter events (and advising everyone that this will be 
the default for all aux threads in Qt 6). But by moving the handling of D-Bus 
events to another thread, we exposed other problems in KUniqueApplication's 
code that assumed that some events would be handled but not some other ones, 
until later.

> What irks me more here is the inconsistent reasoning. I seem to get
> messages of "we need to use this super-duper-but-unreadable XYZ
> construct to save 42.3 bytes in code size" and "well, you know, that's
> just a few hundred lines extra, you won't notice" at the same time
> lately.

Maybe, but that's not the case here.

I'm saying that a proper QtSingleApplication implementation in QtCore may be 
better integrated with QCoreApplication / QGuiApplication / QApplication and 
do away with fragile code that tries to control the lifetime of 
QCoreApplication.

[*] possibly including QEvent::DeferredDelete.

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

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

Re: [Development] QtSingleApplication in Qt proper?

2016-06-20 Thread André Pönitz 
On Mon, Jun 20, 2016 at 02:16:37PM -0700, Thiago Macieira wrote:
> > You mean port away from QApplication?
> > 
> > Anyway, I don't quite get it:
> > 
> > - QtSingleApplication is as easily accessible as other "bread and
> >   butter" parts of Qt via git, hosted by the same entity,
> > 
> > - no other parts of Qt depend on QtSingleApplication nor would
> >   see any kind of UX/Performance/whatever boost if they did,
> > 
> > - we jump through major hoops and put major effort to have something
> >   resembling a modular system with independent repos,
> > 
> > - every now and than we have the feeling that Qt Core / Qt Base
> >   grows too much fat/looks like a dumping ground of nice-to-have
> >   feeatures/whatever and we are not happy
> > 
> > and still we move stuff *needlessly* to Qt Core?
> 
> I'd like to see KUniqueApplication deprecated, as it relies on some 
> undocumented and fragile QtDBus functionality (namely, connecting to
> the bus before QCoreApplication is created).

That's a reason that I have missed so far, but to be honest, I don't
find it convincing.

There's surely a way on the Qt side to overcome the "undocumented" part
of the issue, and the "fragile ... before QCoreApplication is created"
problem is a bit more generic than DBus-only, and, if taken seriously,
might warrant a more generic solution than "incorporate some code to
appease the worst offender".

What irks me more here is the inconsistent reasoning. I seem to get
messages of "we need to use this super-duper-but-unreadable XYZ
construct to save 42.3 bytes in code size" and "well, you know, that's
just a few hundred lines extra, you won't notice" at the same time
lately.

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

Re: [Development] Qt 5.7.0 Toolchain on RasPI2

2016-06-20 Thread Thiago Macieira 
On segunda-feira, 20 de junho de 2016 21:30:09 PDT Alexander Nassian wrote:
> Hi Thiago,
> 
> Would be great if you could be a little bit more specific. I’m using exactly
> the same toolchain and the same sysroot for 5.5.1 and 5.7.0. The 5.5.1
> build works perfectly, the 5.7.0 build fails while linking. Is the GCC
> 4.8.3 which is used for Raspian not supported anymore?

I don't know what differs, but this one you're using, at least the way you're 
using it, is broken. I can't offer more advice as I have never used, developed 
for or even touched a Raspberry Pi, nor Raspbian, nor have I ever used the 
"-device" option for configure.

Your libpthread.so.0 and librt.so.1 are looking for symbols in your libc.so.6 
that they can't find. Qt didn't ship with those libraries, therefore the 
problem is in the toolchain or the way you're using it.

Please make a program that calls clock_gettime(), compiles and links with this 
toolchain (with the -Wl,--no-undefined flag) and will run. Then compare the 
compiler and linker command-lines that you used to the ones that Qt's configure 
script is trying. Find out what's different, then fix the source of those files.

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

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

Re: [Development] QtSingleApplication in Qt proper?

2016-06-20 Thread Thiago Macieira 
On segunda-feira, 20 de junho de 2016 22:57:38 PDT André Pönitz wrote:
> On Mon, Jun 20, 2016 at 07:59:32AM +0200, Kevin Funk wrote:
> > On Donnerstag, 16. Juni 2016 00:19:10 CEST Kevin Funk wrote:
> > > (snip)
> > > 
> > > Question: Is there an interest in having QtSingleApplication in Qt
> > > proper? Say qtbase? We'd love to do the work if there's a chance for
> > > it being accepted.
> > 
> > Heya,
> > 
> > Thanks for all the comments, I'll work on introducing
> > QtSingleApplication into QtCore, including porting it to QLockFile,
> > including porting it away from the QCoreApplication base.
> 
> You mean port away from QApplication?
> 
> Anyway, I don't quite get it:
> 
> - QtSingleApplication is as easily accessible as other "bread and
>   butter" parts of Qt via git, hosted by the same entity,
> 
> - no other parts of Qt depend on QtSingleApplication nor would
>   see any kind of UX/Performance/whatever boost if they did,
> 
> - we jump through major hoops and put major effort to have something
>   resembling a modular system with independent repos,
> 
> - every now and than we have the feeling that Qt Core / Qt Base
>   grows too much fat/looks like a dumping ground of nice-to-have
>   feeatures/whatever and we are not happy
> 
> and still we move stuff *needlessly* to Qt Core?

I'd like to see KUniqueApplication deprecated, as it relies on some 
undocumented and fragile QtDBus functionality (namely, connecting to the bus 
before QCoreApplication is created).

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

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

Re: [Development] QtSingleApplication in Qt proper?

2016-06-20 Thread André Pönitz 
On Mon, Jun 20, 2016 at 07:59:32AM +0200, Kevin Funk wrote:
> On Donnerstag, 16. Juni 2016 00:19:10 CEST Kevin Funk wrote:
> > (snip)
> > 
> > Question: Is there an interest in having QtSingleApplication in Qt
> > proper? Say qtbase? We'd love to do the work if there's a chance for
> > it being accepted.
> 
> Heya,
> 
> Thanks for all the comments, I'll work on introducing
> QtSingleApplication into QtCore, including porting it to QLockFile,
> including porting it away from the QCoreApplication base.

You mean port away from QApplication?

Anyway, I don't quite get it:

- QtSingleApplication is as easily accessible as other "bread and
  butter" parts of Qt via git, hosted by the same entity,

- no other parts of Qt depend on QtSingleApplication nor would 
  see any kind of UX/Performance/whatever boost if they did,

- we jump through major hoops and put major effort to have something
  resembling a modular system with independent repos,

- every now and than we have the feeling that Qt Core / Qt Base
  grows too much fat/looks like a dumping ground of nice-to-have
  feeatures/whatever and we are not happy

and still we move stuff *needlessly* to Qt Core? 

Why?

Because Qt Solutions "feel unmaintained"?

Wouldn't be the natural solution to maintain QtSingleApplication
*there*?

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

Re: [Development] Qt 5.7.0 Toolchain on RasPI2

2016-06-20 Thread Alexander Nassian 
Hi Thiago,

Would be great if you could be a little bit more specific. I’m using exactly 
the same toolchain and the same sysroot for 5.5.1 and 5.7.0. The 5.5.1 build 
works perfectly, the 5.7.0 build fails while linking. Is the GCC 4.8.3 which is 
used for Raspian not supported anymore?


Beste Grüße / Best regards,
Alexander Nassian

> Am 20.06.2016 um 09:02 schrieb Thiago Macieira :
> 
> On domingo, 19 de junho de 2016 21:36:21 PDT Alexander Nassian wrote:
>> EGLFS and others were disabled because of the already mentioned linker
>> error.
>> 
>> /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-g
>> nueabihf/libpthread.so.0: undefined reference to `__mktemp@GLIBC_PRIVATE'
> 
> This is a toolchain error. Fix your toolchain.
> 
> 
> -- 
> 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] QtSingleApplication in Qt proper?

2016-06-20 Thread charleyb123 
+1, I've found many good uses for QtSingleApplication, and think this is a
good (highly practical) feature for "Qt-proper".

--charley


On Sun, Jun 19, 2016 at 11:59 PM, Kevin Funk  wrote:

> On Donnerstag, 16. Juni 2016 00:19:10 CEST Kevin Funk wrote:
> > (snip)
> >
> > Question:
> >   Is there an interest in having QtSingleApplication in Qt proper? Say
> > qtbase? We'd love to do the work if there's a chance for it being
> accepted.
>
> Heya,
>
> Thanks for all the comments, I'll work on introducing QtSingleApplication
> into
> QtCore, including porting it to QLockFile, including porting it away from
> the
> QCoreApplication base.
>
> Hopefully within the upcoming weeks if I find the time.
>
> Cheers,
> Kevin
>
> > (snip)
>
> --
> Kevin Funk | kf...@kde.org | http://kfunk.org
> ___
> 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] Revisiting high-DPI configuration options

2016-06-20 Thread Thiago Macieira 
On segunda-feira, 20 de junho de 2016 14:30:19 PDT Shawn Rutledge wrote:
> Don’t you think there should be a quirks database somewhere (outside of Qt)
> which corrects these cases?  The TV model can be identified, right?
 
> X does it, but that’s not a broad enough scope to cover Wayland.
> 
> https://wiki.ubuntu.com/X/Quirks#Monitor_Quirks 
> 
> Maybe it could be done with udev rules or something.  If there is really not
> yet a proper solution on Linux, there should be, IMO.

We would need a correction database, not just a quirks one.

160x90 mm is a valid screen size, correspoding to a 7.2" monitor.

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

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

Re: [Development] QStorageinfo changes: a bug.

2016-06-20 Thread Thiago Macieira 
On segunda-feira, 20 de junho de 2016 11:45:23 PDT Stef Bon wrote:
> This worked until recently, now the fuse is not found anymore. I've
> found out that the function
> isPseudoFs has been changed, and every fs where the device does not
> start with a slash is a pseudofs. Huhhh? This is far too strict.

That matches all the cases of pseudo-fs for me. It's not required, though, as 
you can mount anything in a pseudo-fs and it will be ignored.

> The manpage of mount describes for the device (or source):
> 
> mount()  attaches the filesystem specified by source (which is often a
> device name, but can also be a directory name or a dummy) to the
> directory specified by target.
> 
> So there are no restrictions here it has to start with a slash. And
> the source --can-- be something abstract, and not a device.

You're reading it upside down, mistaking "sufficient" condition for "required".

As you and I both said, it's not required to start with something other than a 
slash. But it is sufficient for me, as a real FS will require a real device to 
be mounted and a real device requires a device node or another file path.

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

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

Re: [Development] Proposal For Qt 5.8 Platforms And SW Updates

2016-06-20 Thread Jake Petroules 
Looks good to me. Note that it's macOS now, not OS X.

On Jun 20, 2016, at 5:15 AM, Heikki Halmet 
> wrote:

Hi,

Below is our proposal for target platforms and sw updates in Qt 5.8 release.
Some might come after feature freeze or some changes might not happen at all.

OpenSUSE 42.1 x86_64 ( - OpenSUSE 13.1 will be dropped after 42.1 is in)
• Openssl: 1.0.2h
Rhel 6.6 (build's packages) & Rhel 7.2 x86_64 (will appear as a developer build)
• Openssl: 1.0.2h
• Android ndk r10e
• Android sdk 25.1.7
• Python-devel (or python-dev)
Ubuntu 16.04 x86_64 ( - Will drop Ubuntu 14.04 and 15.04 when it's in)
• Openssl: 1.0.2h
• Python-devel (or python-dev)
OS X 10.12 beta
• Xcode 8 beta & command line tools
• Android ndk r10e
• Android sdk 25.1.7
OS X 10.11.5 x86_64
• Xcode 7.3.1 & command line tools
• Android ndk r10e
• Android sdk 25.1.7
OS X 10.10 x86_64
OS X 10.9 x86_64
OSX 10.8 will be dropped!
Windows 10 x86
• Openssl: 1.0.2h
• Visual Studio 2015 update 2
Windows 10 x86_64
• Openssl: 1.0.2h
• Visual Studio 2015 update 2
Windows 7 x86
• Openssl: 1.0.2h
• Android ndk r10e
• Android sdk 25.1.7
• MinGw 5.3.0
Windows 8.1 x86
• Openssl: 1.0.2h
• Visual Studio 2013 update 5
Windows 8.1 x86_64
• Openssl: 1.0.2h (latest)
• Visual Studio 2013 update 5


Best regards
Heikki Halmet

The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland
Email: heikki.hal...@qt.io
Phone: +358408672112
www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: 
@qtproject, @Qtproject Facebook: www.facebook.com/qt


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

--
Jake Petroules - jake.petrou...@qt.io
Consulting Services Engineer - The Qt Company
Qbs build system evangelist - qbs.io

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

Re: [Development] Revisiting high-DPI configuration options

2016-06-20 Thread Shawn Rutledge 

> On 17 Jun 2016, at 22:49, Thiago Macieira  wrote:
> 
>> - Run "./highdpi --metrics", or test with an application.
> 
> See 3 scenarios attached. I'll send a fourth scenario later, when I try at 
> home with my 45" TV that reports its size as 160 x 90 mm.

Don’t you think there should be a quirks database somewhere (outside of Qt) 
which corrects these cases?  The TV model can be identified, right?

X does it, but that’s not a broad enough scope to cover Wayland.

https://wiki.ubuntu.com/X/Quirks#Monitor_Quirks 

Maybe it could be done with udev rules or something.  If there is really not 
yet a proper solution on Linux, there should be, IMO.

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

Re: [Development] Revisiting high-DPI configuration options

2016-06-20 Thread Morten Sorvig 

> On 17 Jun 2016, at 14:54, Frank Hemer  wrote:
> 
> Can you give a hint on what causes these glitches and how to avoid them?
> I'm not talking about general usage of fractional methods for painting here. 
> 
> For example when drawing to a pixmap (sized for the 'real' screen resolution) 
> and then updating just a sub-rectangle of this pixmap, for some (and really 
> only some) fractional scale factor values there are glitches around that sub-
> rectangle where the background color of the window shines through.
> What is causing this?

I have not analyzed these in detail, but my guess would be rounding errors
due to fractional coordinates. So you could look at the update code (in QPainter
or the paint engine) and make sure coordinates are rounded to _include_
partially covered pixels.

> 
> What is the reason for not aiming towards supporting fractional scale factors 
> on the long run? What is the real challenge here?
> 

Good question!

If you ask me I think the Qt project should move towards supporting this (taking
care to avoid maintenance traps such as the native styles). One of the 
challenges
is simply available time and resources for doing the work. But even today Qt 
Creator
at QT_SCALE_FACTOR=1.3 is a usable application.

Another reason to not spend time on it would be that integer is, or is going
to be, the dominating use case. Wayland and Apple is integer, so are most of
the Android device categories. For Windows and desktop in general there are
currently lots of fractional hardware and configurations.

Morten



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

Re: [Development] QStorageinfo changes: a bug.

2016-06-20 Thread Stef Bon 
2016-06-20 14:48 GMT+02:00 Shawn Rutledge :
>

>
> Apparently you are referring to https://codereview.qt-project.org/#/c/141217/
>

Yes.

> Please report a bug, and give any ideas you have for deciding what is a 
> pseudo-fs and what isn’t.  I don’t think we can say that every FUSE 
> filesystem falls into either category, right?
>

I've reported a bug/suggestion just right now:

https://bugreports.qt.io/browse/QTBUG-54235

The suggestion I do is adding filters simular to QDir::entryInfoList,
where the default without filters is the current.

And maybe the whole name "storageinfo" is misleading. Just
QFilesystemsInfo would be better.

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

Re: [Development] QStorageinfo changes: a bug.

2016-06-20 Thread Shawn Rutledge 

> On 20 Jun 2016, at 11:45, Stef Bon  wrote:
> 
> Hi,
> 
> I've found aout that the qstorageinfo has changed recently. I'v got a
> fuse filesystem and a qt gui using that filesystem. To detect the
> mountpoint the gui uses QStorageInfo::mountedVolumes() and walk this
> list.
> 
> This worked until recently, now the fuse is not found anymore. I've
> found out that the function
> isPseudoFs has been changed, and every fs where the device does not
> start with a slash is a pseudofs. Huhhh? This is far too strict.
> 
> The manpage of mount describes for the device (or source):
> 
> mount()  attaches the filesystem specified by source (which is often a
> device name, but can also be a directory name or a dummy) to the
> directory specified by target.
> 
> So there are no restrictions here it has to start with a slash. And
> the source --can-- be something abstract, and not a device.

Apparently you are referring to https://codereview.qt-project.org/#/c/141217/

Please report a bug, and give any ideas you have for deciding what is a 
pseudo-fs and what isn’t.  I don’t think we can say that every FUSE filesystem 
falls into either category, right?

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

[Development] Common consensus about isExposed()?

2016-06-20 Thread Milla Pohjanheimo 
It looks like isExposed() has it's own interpretation of the implementation on 
each platform. See bug: https://bugreports.qt.io/browse/QTBUG-53252 
"isExposed() returns true also if window minimized or completely covered". Our 
autotests are heavily relying on the result of qWaitForWindowExposed() (in 
qtbase/src/testlib/qtestsystem.h) which gets the result from isExposed(). This 
causes flakiness in the tests. See also this task: 
https://bugreports.qt.io/browse/QTBUG-52594 "Make a platform-aware 
qWaitForWindowExposed()/Active()".


I would like to raise discussion on how do you think this should be addressed.


See Gatis's last comment in the bug report:

"1) Agree on what exposed means -> improve documentation -> fix code in all 
platform plugins.
2) Deprecate API and find some other alternative for auto tests?
3) Something else?"

What do you think?

- Milla






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

[Development] Proposal For Qt 5.8 Platforms And SW Updates

2016-06-20 Thread Heikki Halmet 
Hi,

Below is our proposal for target platforms and sw updates in Qt 5.8 release.
Some might come after feature freeze or some changes might not happen at all.

OpenSUSE 42.1 x86_64 ( - OpenSUSE 13.1 will be dropped after 42.1 is in)
* Openssl: 1.0.2h
Rhel 6.6 (build's packages) & Rhel 7.2 x86_64 (will appear as a developer build)
* Openssl: 1.0.2h
* Android ndk r10e
* Android sdk 25.1.7
* Python-devel (or python-dev)
Ubuntu 16.04 x86_64 ( - Will drop Ubuntu 14.04 and 15.04 when it's in)
* Openssl: 1.0.2h
* Python-devel (or python-dev)
OS X 10.12 beta
* Xcode 8 beta & command line tools
* Android ndk r10e
* Android sdk 25.1.7
OS X 10.11.5 x86_64
* Xcode 7.3.1 & command line tools
* Android ndk r10e
* Android sdk 25.1.7
OS X 10.10 x86_64
OS X 10.9 x86_64
OSX 10.8 will be dropped!
Windows 10 x86
* Openssl: 1.0.2h
* Visual Studio 2015 update 2
Windows 10 x86_64
* Openssl: 1.0.2h
* Visual Studio 2015 update 2
Windows 7 x86
* Openssl: 1.0.2h
* Android ndk r10e
* Android sdk 25.1.7
* MinGw 5.3.0
Windows 8.1 x86
* Openssl: 1.0.2h
* Visual Studio 2013 update 5
Windows 8.1 x86_64
* Openssl: 1.0.2h (latest)
* Visual Studio 2013 update 5


Best regards
Heikki Halmet

The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland
Email: heikki.hal...@qt.io
Phone: +358408672112
www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: 
@qtproject, @Qtproject Facebook: www.facebook.com/qt


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

Re: [Development] Qt 5.8 branching & Feature Freeze

2016-06-20 Thread Jani Heikkinen 
Hi all,


It seems there isn't that much objections to proposed schedule. Tony's points 
are valid but after discussion with several persons we agree it isn't necessary 
to postpone feature freeze because of missing platforms/versions from CI. So 
let's proceed with proposed schedule to be able to release Qt 5.8.0 still 
during this year:


- Branching from 'dev' to '5.8' starts 2.8.2016

- Qt 5.8 feature freeze 9.8.2016


Please make sure all new features are really in 'dev' well before actual 
feature freeze date (and fulfilling the FF criteria: 
https://wiki.qt.io/Qt5_feature_freeze). Also make sure all new submodules (also 
technology preview ones) are in qt5.git (.gitmodules) early enough. By default 
all modules missing at FF date will be out from Qt 5.8 release (Lars can give 
an exception by request but we should really avoid that).


Please start updating Qt 5.8.0 new features page here: 
https://wiki.qt.io/New_Features_in_Qt_5.8 .



br,

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

Re: [Development] QtSerialBus : Function Code 20 and 21 not implemented

2016-06-20 Thread Karsten Heimrich 
Hi Vincent,

we just didn't manage to implement all functionallity provided by the 
specification. Right now there is no pending patch or implementation I know of, 
but we are definitifly looking into finishing it for a later release. Of 
course, if you need the functionality you can implement it on your own by 
inheriting from one of the QModbusServer descendants. We are also open for 
patches that provide the missing implementation.

Obviously you found the issue on jira already: 
https://bugreports.qt.io/browse/QTBUG-49510?filter=17150

Regards,

Karsten Heimrich
Senior Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
karsten.heimr...@qt.io
http://qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png]




From: Development 
[mailto:development-bounces+karsten.heimrich=qt...@qt-project.org] On Behalf Of 
SENECLAUZE Vincent
Sent: Freitag, 17. Juni 2016 17:02
To: development@qt-project.org
Subject: [Development] QtSerialBus : Function Code 20 and 21 not implemented

Hi everyone,

I try to use the new QtSerialBus with the Qt 5.7.0, and during my test, the 
Function Code 20 and 21 answer Illegal Function.

When I opened source code, I saw this :

Line 662, File qmodbusserver.cpp :
case QModbusRequest::ReadFileRecord:// TODO: Implement.
case QModbusRequest::WriteFileRecord:   // TODO: Implement.
return QModbusExceptionResponse(request.functionCode(),
QModbusExceptionResponse::IllegalFunction);

My questions are :

Why the documentation do not precise that this Function Code is not implemented 
?
And
Is there a plan to finish this implementation in the next release ? or is 
someone have a kind of begining of source code or patch ?

Best regards,

Vincent SENECLAUZE



__

Ce message et toutes les pièces jointes (ci-après le "message") sont 
confidentiels et établis à l'intention exclusive de ses destinataires.
Toute modification, édition, utilisation ou diffusion non autorisée est 
interdite.
Tout message électronique est susceptible d'altération.
SPIE et ses filiales déclinent toute responsabilité au titre de ce message s'il 
a été altéré, déformé, falsifié, édité ou diffusé sans autorisation.

This message and any attachments (the "message") are confidential and intended 
solely for the addressees.
Any unauthorised alteration , printing , use or dissemination is prohibited.
E-mails are susceptible to alteration.
SPIE nor any of its subsidiaries or affiliates shall be liable for the message 
if altered, changed, falsified, printed or disseminated without authorisation.
__
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.7.0 Toolchain on RasPI2

2016-06-20 Thread Thiago Macieira 
On domingo, 19 de junho de 2016 21:36:21 PDT Alexander Nassian wrote:
> EGLFS and others were disabled because of the already mentioned linker
> error.
> 
> /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-g
> nueabihf/libpthread.so.0: undefined reference to `__mktemp@GLIBC_PRIVATE'

This is a toolchain error. Fix your toolchain.


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

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

Re: [Development] QtSingleApplication in Qt proper?

2016-06-20 Thread Kevin Funk 
On Donnerstag, 16. Juni 2016 00:19:10 CEST Kevin Funk wrote:
> (snip)
> 
> Question:
>   Is there an interest in having QtSingleApplication in Qt proper? Say
> qtbase? We'd love to do the work if there's a chance for it being accepted.

Heya,

Thanks for all the comments, I'll work on introducing QtSingleApplication into 
QtCore, including porting it to QLockFile, including porting it away from the 
QCoreApplication base.

Hopefully within the upcoming weeks if I find the time.

Cheers,
Kevin

> (snip)

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

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