Re: [Development] Re : QtSerialPort addon Wiki. Need spelling checking for English.

[Denis Shienkov]

Hi.

Yes, something like this.

Best regards,
Denis

13.03.2012, 00:47, "1+1=2" :
> On Mon, Mar 12, 2012 at 12:22 PM, Davet Jacques  wrote:
>
>>  Hi,
>>
>>  I went over it and fixed most of
>>  the text to make it grammatically correct and nicer to read, but I don't 
>> understand what the following paragraph is supposed to mean (in the
>>  "SerialPort" section):
>>>  For the standard implementation of the internal structure and interfaces
>>>  was adopted class QAbstractSocket, as one of the most suitable in
>>>  terms of functionality. In this case, the internal structure used by
>>>  QAbstractSocket, was significantly revised and simplified.
>>  "standard implementation"
>>
>>  Are
>>   there multiple implementations? Or is it simply supposed to refer to
>>  the "core" / "technical foundation" of the implementation?
>>
>>  "internal structure and interfaces was adopted ..."
>>  "internal structure [...] was significantly revised and simplified"
>>
>>  Does this mean ...
>>
>>   - SerialPort is a subclass of QAbstractSocket?
>>  or
>>   - SerialPort is a fork of QAbstractSocket?
>>  or
>>   - SerialPort is inspired by QAbstractSocket / follows the API-conventions 
>> defined by QAbstractSocket?
>
> In my opinion, It should be this:
> SerialPort is inspired by QAbstractSocket, and their implementation
> have similiar architecture.
>
> Best regards,
>
> Debao
> ___
> 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] QtSerialPort addon Wiki. Need spelling checking for English.

[Denis Shienkov]

Hi Davet.

1. QAbstractSocket is etalon, example to follow for class SerialPort.
ie most likely this:
>  - SerialPort is inspired by QAbstractSocket / follows the API-conventions 
> defined by QAbstractSocket?

2. QPrinterInfo is etalon, example to follow for class SerialPortInfo.

Ie general principles of architecture classes QAbstractSocket and QPrinterInfo 
adopted 
to QtSerialPort module (their behavior and implementation).

Best regards, 
Denis.

12.03.2012, 23:22, "Davet Jacques" :
> Hi,
>
> I went over it and fixed most of
> the text to make it grammatically correct and nicer to read, but I don't 
> understand what the following paragraph is supposed to mean (in the
> "SerialPort" section):
>
>>  For the standard implementation of the internal structure and interfaces
>>  was adopted class QAbstractSocket, as one of the most suitable in
>>  terms of functionality. In this case, the internal structure used by
>>  QAbstractSocket, was significantly revised and simplified.
>
> "standard implementation"
>
> Are
>  there multiple implementations? Or is it simply supposed to refer to
> the "core" / "technical foundation" of the implementation?
>
> "internal structure and interfaces was adopted ..."
> "internal structure [...] was significantly revised and simplified"
>
> Does this mean ...
>
>  - SerialPort is a subclass of QAbstractSocket?
> or
>  - SerialPort is a fork of QAbstractSocket?
> or
>  - SerialPort is inspired by QAbstractSocket / follows the API-conventions 
> defined by QAbstractSocket?
>
> The same goes for this similar paragraph (in the "SerialPortInfo" section):
>
>>  For the standard implementation of the internal structure and interfaces
>>  was adopted class QPrinterInfo, as one of the most suitable in terms
>>  of functionality.
>
> Again: What exactly is the relation between the SerialPortInfo and 
> QPrinterInfo classes?
>
> Regards,
>
>   Davet Jacques
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QLogging with wildcards categories

[wolfgang.beck]

Hi guys,

A new patch is ready.
Logging into a file is now removed because of possible maintenance trouble.
http://codereview.qt-project.org/#change,13226

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

Re: [Development] Demos, examples, docs etc for Alpha release

[marius.storm-olsen]

On 12/03/2012 18:10, ext Quim Gil wrote:
> Also, a basic question: where can someone find the actual list of
> Essential and Add-on modules that will be included in the Alpha? A
> Work-in-progress list is fine, now the only reference I have is a
> slide from last October-November.

The current release script generates a package (890MB tar => 251MB 
tar.gz), correlated with the categorization of modules at 
http://qt-project.org/wiki/Qt_5.0 and corrected with some recent 
discussions between Henry, Lars and Thiago, this list of modules:

Qt Essentials:
 qt3d
 qtcore
 qtdeclarative
 qtgui
 qtjsbackend
 qtlocation
 qtmultimedia
 qtnetwork
 qtsql
 qttestlib
 qtwebkit

Qt Add-ons:
 qlalr
 qtactiveqt
 qtconcurrent
 qtconnectivity
 qtdbus
 qtdoc
 qtdocgallery
 qtfeedback
 qtgraphicaleffects
 qtimageformats
 qtjsondb
 qtphonon
 qtpim
 qtplatformsupport
 qtprintsupport
 qtqa
 qtquick1
 qtrepotools
 qtscript
 qtscripttools
 qtsensors
 qtsvg
 qtsystems
 qttools
 qttranslations
 qtwayland
 qtwebkit-examples-and-demos
 qtwidgets
 qtxml
 qtxmlpatterns

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

[Development] qt5 build support mips toolchain

[tang ke]

hi all:
I want to build the qt5 with cross-toolchain, the target arch is mips, 
the qt5 build support it?


thanks a lot

Tang Ke

--
Best Regards


Tang Ke (Application develop of software department)
Tel：0086-512-52308628 Fax：0086-512-52308688
Phone:18962393077
E-mail:ta...@lemote.com  MSN：ta...@lemote.com, mumut...@gmail.com
Web: http://www.lemote.com
JiangSu ZhongKe Lemote Technology Co.,Ltd
MengLan Industry Park,YuShan,ChangShu City,JiangSu,China

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

Re: [Development] Demos, examples, docs etc for Alpha release

[Quim Gil]

I have been gathering more info & reality checks for the alpha 
announcement and release notes, and I hope to have a first draft by the 
end of tomorrow PST.

We have three big themes:

- Graphics performance: Qt Quick 2 (GL based scene graph, particle 
system, shader effects), Qt Quick 3D, QtOpenGL, graphics effects, video 
effects, MediaHub...

- Web technologies: QtWebKit2, V8, JsonDB, what else? I reached to the 
QtWebKit mailing list for help.

- Portability: QPA for real. Since the alpha release itself won't be 
available in many targets I'd welcome blog posts, testimonials video 
proof points etc of teams playing with Qt 5 & QPA on different targets. 
For instance, it would be great to see MediaHub or any of the 
QtDeclarative examples running on different targets.

Also, a basic question: where can someone find the actual list of 
Essential and Add-on modules that will be included in the Alpha? A 
Work-in-progress list is fine, now the only reference I have is a slide 
from last October-November.

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

Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1

[Rohan McGovern]

Richard Moore said:
> On 12 March 2012 17:56,   wrote:
> > Besides flaky tests, we also have the general/recurring problem of changes 
> > going into qtbase that break qtdeclarative (and possibly/likely other 
> > modules). While I realize it's time-consuming for everyone to manually 
> > build and run the qtdeclarative tests (or entire qt5.git) when you're 
> > working on qtbase, please at least take the time to consider how your 
> > change might affect other modules. If you're unsure and/or would like 
> > someone else's opinion on the possible impact, feel free to send an email 
> > to this list, or ask on IRC. Thanks.
> 
> Do you have any idea of how many of these were due to QtDeclarative
> making assumptions that aren't part of the defined API, vs how many
> were changes in expected behaviour?

Here's the commits which were needed:

http://codereview.qt-project.org/18941 - 406f741 Remove pin of qtbase for 
qtdeclarative.
  -> the one removing the pin, not actually resolving any test failures.

http://codereview.qt-project.org/18909 - 16e29f3 Remove unneeded 
dependencies to QtWidgets and QtOpenGL
  -> I don't think this one resolves any test failures.

http://codereview.qt-project.org/19656 - c787809 Mark presumed unstable 
test as insignificant.
  -> marks tst_qquickpixmapcache as insignificant, doesn't actually
 resolve the problem, so the real issue may not yet be understood

http://codereview.qt-project.org/19552 - dda130f Fix MouseArea autotest.
http://codereview.qt-project.org/19534 - 6cf36b2 Fix tst_qquicktextedit.
http://codereview.qt-project.org/19427 - cb1ff7a Fix double click handler 
in QQuickItem.
  -> all of these were failing due to changes in double-click
 semantics, apparently a bug fix:

commit b371f3f943703840d0dfbe30505018bcca06e260
Author: Laszlo Agocs 
Date:   Tue Mar 6 16:09:09 2012 +0200

Fix double click handling.

Until now double clicking in Qt 5 resulted in the following 
sequence of mouse
events: pressed, released, double clicked, released. This is wrong, 
the press
belonging to the second button down is missing. In Qt 4 that 
pressed event is
present.

 There were also some follow-up commits to this one, I am not
 sure exactly which one triggered the problems.

 Probably all of the failing tests were created or updated while
 qtbase had the buggy double-click behavior.  Then they started
 to fail when the bug was fixed in qtbase.

 It's still unclear to me if the actual behavior matches what is
 documented, e.g. http://doc.qt.nokia.com/5.0-snapshot/qwidget.html says
 "If the user double-clicks, the widget receives a mouse press
 event, a mouse release event and finally this event instead of
 a second mouse press event", vs Laszlo's comment in
 tst_qquickmousearea, "press, release, (click), press, double click,
 release".

http://codereview.qt-project.org/19598 - cbb7f8b Skip test that accesses 
deleted QML engine
  -> apparently the test reads invalid memory, but doesn't actually
 crash on most platforms.  It might be that the qtbase changes,
 due to changing the layout of a few things in memory, caused it
 to start crashing on at least one platform.

http://codereview.qt-project.org/19636 - 2553575 Fix flakiness in 
qquicklistmodel autotest
  -> the test was buggy, it had a race condition which may have been
 triggered by someone making some code faster, or perhaps
 reducing the amount of round trips through the event loop
 required for one tested condition to become true.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QDoc can't ignore Q_PROPERTY

[casper.vandonderen]

So let's step back for a bit:

>> I get not wanting to be forced into writing redundant 'emitted when
>> this property has changed' documentation but excluding documentation
>> that has been written for a signal seems a bit excessive, wouldn't it
>> be enough to just omit the warning for an undocumented signal if it's
>> a notify signal?
>
> That would work but the code to do that would be more complicated (can't
> just suppress warnings, must do "document as property" or "document as
> signal" depending on if the signal docs are found). Since I don't
> actually know the qdoc code, I went for a simple fix.
>
> If the above design pattern (co-opting a signal for NOTIFY) is common
> and suppressing the documentation for those signals will be a problem
> then I guess the more complicated fix will need to be done.

The solution given above would mean that it will become optional to document 
NOTIFY signals.
But is that not completely different from the original problem?

To me it seems like the original problem was that method documentation would 
not show up when a property had the same name. Or did I misunderstand that?


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

Re: [Development] Re : QtSerialPort addon Wiki. Need spelling checking for English.

[1+1=2]

On Mon, Mar 12, 2012 at 12:22 PM, Davet Jacques  wrote:
> Hi,
>
>
> I went over it and fixed most of
> the text to make it grammatically correct and nicer to read, but I don't 
> understand what the following paragraph is supposed to mean (in the
> "SerialPort" section):
>
>> For the standard implementation of the internal structure and interfaces
>> was adopted class QAbstractSocket, as one of the most suitable in
>> terms of functionality. In this case, the internal structure used by
>> QAbstractSocket, was significantly revised and simplified.
>
> "standard implementation"
>
> Are
>  there multiple implementations? Or is it simply supposed to refer to
> the "core" / "technical foundation" of the implementation?
>
> "internal structure and interfaces was adopted ..."
> "internal structure [...] was significantly revised and simplified"
>
> Does this mean ...
>
>  - SerialPort is a subclass of QAbstractSocket?
> or
>  - SerialPort is a fork of QAbstractSocket?
> or
>  - SerialPort is inspired by QAbstractSocket / follows the API-conventions 
> defined by QAbstractSocket?

In my opinion, It should be this:
SerialPort is inspired by QAbstractSocket, and their implementation
have similiar architecture.

Best regards,

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

Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1

[Richard Moore]

On 12 March 2012 17:56,   wrote:
> Besides flaky tests, we also have the general/recurring problem of changes 
> going into qtbase that break qtdeclarative (and possibly/likely other 
> modules). While I realize it's time-consuming for everyone to manually build 
> and run the qtdeclarative tests (or entire qt5.git) when you're working on 
> qtbase, please at least take the time to consider how your change might 
> affect other modules. If you're unsure and/or would like someone else's 
> opinion on the possible impact, feel free to send an email to this list, or 
> ask on IRC. Thanks.

Do you have any idea of how many of these were due to QtDeclarative
making assumptions that aren't part of the defined API, vs how many
were changes in expected behaviour? If you have identified cases of
the latter then we should be adding unit tests for them, if we have
cases of the former then tbh that's a bug in QtDeclarative.

Cheers

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

Re: [Development] Qt Playground - Command Line Parser experiment

[marius.storm-olsen]

On 08/03/2012 17:36, ext Laszlo Papp wrote:
> It is not a separate module, but class(es). The name for this
> experiment, in playground, would be something like "Command Line
> Parser". According to the regulation: if nobody objects to this
> addition from the beginning, I need to get the support of one
> existing module maintainer in order to be able to experiment with
> this feature in playground.

Like Ossi said, normally this would just be a feature branch, due to 
their natural fitting into existing modules. However, this case is 
special. See below.


> Either way, please let me know your thoughts. Thank you in advance!

It has been a long tradition inside Trolltech, and later Qt Development 
Frameworks that all new employees come with a bright idea to implement a 
command-line parser. After all, the Qt framework doesn't come with any, 
so it must certainly somehow have been forgotten.

Not so. We probably have 10-12 command-line parsers developed throughout 
the years, but none of them have ever been included in the product. 
Mostly because either,

a) The parser is too trivial and doesn't handle the normal levels of 
complexity of command line arguments out there. (tar, find, zip, and 
standard Qt (built-in) arguments anyone?)

b) The parser is too complex, where it doesn't live up to the simplicity 
expected from Qt API and usage.

c) The parser only focuses on the "standard" for a single platform. 
(Linux users will not go for Windows style /? options, and Windows users 
won't accept --help Linux options, etc)

The problems with writing a parser like this is to make it general 
enough to support most of the Qt users, to justify it being part of the 
core set of modules. If it doesn't, it probably shouldn't be in QtBase, 
and as such should be a separate Addon, IMO.

Anyways, something to keep in mind when working on your implementation. 
It's a can of worms with *a lot* of bikeshedding ;)

Good luck!

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

[Development] Re : QtSerialPort addon Wiki. Need spelling checking for English.

[Davet Jacques]

Hi,


I went over it and fixed most of 
the text to make it grammatically correct and nicer to read, but I don't 
understand what the following paragraph is supposed to mean (in the 
"SerialPort" section):

> For the standard implementation of the internal structure and interfaces
> was adopted class QAbstractSocket, as one of the most suitable in
> terms of functionality. In this case, the internal structure used by 
> QAbstractSocket, was significantly revised and simplified.

"standard implementation"

Are
 there multiple implementations? Or is it simply supposed to refer to 
the "core" / "technical foundation" of the implementation?

"internal structure and interfaces was adopted ..."
"internal structure [...] was significantly revised and simplified"

Does this mean ...

 - SerialPort is a subclass of QAbstractSocket?
or
 - SerialPort is a fork of QAbstractSocket?
or
 - SerialPort is inspired by QAbstractSocket / follows the API-conventions 
defined by QAbstractSocket?

The same goes for this similar paragraph (in the "SerialPortInfo" section):

> For the standard implementation of the internal structure and interfaces
> was adopted class QPrinterInfo, as one of the most suitable in terms
> of functionality.

Again: What exactly is the relation between the SerialPortInfo and QPrinterInfo 
classes?

Regards,

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

Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1

[Thiago Macieira]

On segunda-feira, 12 de março de 2012 17.56.14, kent.han...@nokia.com wrote:
> Hi,
> After 4 CI rounds, the sucker finally got merged: qtdeclarative/master is
> tracking qtbase/master again. In the end we needed to stage eight changes
> at the same time to get it through, due to various flaky autotests and
> whatnot.
>
> Besides flaky tests, we also have the general/recurring problem of changes
> going into qtbase that break qtdeclarative (and possibly/likely other
> modules). While I realize it's time-consuming for everyone to manually
> build and run the qtdeclarative tests (or entire qt5.git) when you're
> working on qtbase, please at least take the time to consider how your
> change might affect other modules. If you're unsure and/or would like
> someone else's opinion on the possible impact, feel free to send an email
> to this list, or ask on IRC. Thanks.

Can you tell us which changes were necessary to fix the compilation? Knowing
which areas have caused issues in the past might help targeting in the future.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1

[kent.hansen]

Hi,
After 4 CI rounds, the sucker finally got merged: qtdeclarative/master is 
tracking qtbase/master again. In the end we needed to stage eight changes at 
the same time to get it through, due to various flaky autotests and whatnot.

Besides flaky tests, we also have the general/recurring problem of changes 
going into qtbase that break qtdeclarative (and possibly/likely other modules). 
While I realize it's time-consuming for everyone to manually build and run the 
qtdeclarative tests (or entire qt5.git) when you're working on qtbase, please 
at least take the time to consider how your change might affect other modules. 
If you're unsure and/or would like someone else's opinion on the possible 
impact, feel free to send an email to this list, or ask on IRC. Thanks.

Best regards,
Kent 


From: development-bounces+kent.hansen=nokia@qt-project.org 
[development-bounces+kent.hansen=nokia@qt-project.org] on behalf of Hansen 
Kent (Nokia-MP/Oslo)
Sent: Monday, March 12, 2012 10:21 AM
To: development@qt-project.org
Subject: [Development] Staging of qtdeclarative changes has been blocked while 
we try to unpin the qtbase SHA1

Hi,
qtdeclarative needs to be adapted to some recent changes in qtbase.
While we try to get that done
(http://codereview.qt-project.org/#change,18941), staging of unrelated
changes to qtdeclarative has been blocked.

Best regards,
Kent
___
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] [Releasing] Qt 4.8.1 open source release date approaching..

[shane.kearns]

> On Fri, Mar 09, 2012 at 07:16:24PM +, ext
> shane.kea...@accenture.com wrote:
> >
> > (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix
> >  \
> >   fix(rc2)-fix(v4.8.1)
> >
> this is no option, because it "loses" the tag from the history.
> "traditionally" we have merged back the release branch to the
> maintenance branch (and thus to master), which means that we have all
> those cherry-picks twice in the history. try to read *that*.
> therefore the only clean options are either a) just don't create a
> branch or b) if you create a branch, then apply any fixes which are
> supposed to be in it *only* to that branch, so it can be cleanly
> forward-merged.
>

The full picture including the merge back would look like:

 (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix-o-o-o-M
 \  /
  fix(rc2)-fix(v4.8.1)-.

The tag has to be on the branch (if there is a branch), otherwise "git checkout 
v4.8.1" doesn't give the same thing as the release tarball.
Tools that show the history including branches (e.g. gitk) would give a picture 
like what's above, "git log" will show the cherry picks twice in the history.
The history is unreadable for v4.8.0 because of the 7 parallel staging 
branches, but displaying two parallel branches (4.8 and 4.8.1) should be sane 
and readable.
I believe that "git log v4.8.1.." includes the commits which came in with the 
merge (anything on 4.8 but not on 4.8.1 branch)


Subject to local law, communications with Accenture and its affiliates 
including telephone calls and emails (including content), may be monitored by 
our systems for the purposes of security and the assessment of internal 
compliance with Accenture policy.
__

www.accenture.com

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

Re: [Development] QServiceClientCredentials

[andrew.stanley-jones]

Documentation will be added/updated in the near future.  I've been rather
busy
recently, and it was more important to make the API available.

Any assistance is appreciated of course,

-Andrew

--
Andrew Stanley-Jones, Software Engineer
Nokia, Qt, Brisbane
http://qt.nokia.com/



On 12/03/12 5:01 PM, "ext Thomas Senyk"  wrote:

>On Monday, March 12, 2012 02:53:32 PM Blasche Alex wrote:
>> Hi Thomas,
>> 
>> > -Original Message-
>> > From: development-bounces+alex.blasche=nokia@qt-project.org
>> > [mailto:development-bounces+alex.blasche=nokia@qt-project.org] On
>> > 
>> > What's up with the remote-service-cedentials?
>> > It seams to be only part of the documentation, but no class, struct or
>> > anything else in Qt5 QtLocation
>> 
>> The class is part of the Qt ServiceFramework module
>> (qtsystems/src/serviceframework) and not the Qt Location module.
>
>right, just a "typo" @ location
>
>And after doing the right grep I found it :) It's still called
>QRemoteServiceRegisterCredentials
>
>... as it's called in the QtMobility code and doc, but it's call
>QServiceClientCredentials
>in the Qt5 doc.
>
>Any reason for the mismatch?
>
>
>> 
>> --
>> Alex
>> 
>> > It's still part of the documentation:
>> > http://doc.qt.nokia.com/qt5/service-frameworks.html#service-security
>> > 
>> > 
>> > Greets
>> > Thomas
>> > ___
>> > 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

Re: [Development] Breaking up QtPlatformSupport

[Thiago Macieira]

On segunda-feira, 12 de março de 2012 15.28.01, gunnar.sle...@nokia.com wrote:
> > Building plugins outside of QtBase will continue to be permitted, provided
> > they don't use QtPlatformSupport. That library is just convenience for us.
> > There is absolutely no public API there. If there are things needed by
> > many
> > plugins, we should consider making proper, public API instead.
>
> Not only will building platform plugins outside QtBase be permitted, it will
> in fact be the primary usecase if we consider Qt's future on embedded
> devices. Most good adaptations will want to do something hardware specific.
> It is not just convenience for us inside QtBase.
>
> We can talk about making it into a nicer API in a future version of Qt, but
> for Qt 5, we should keep it as it is.

Understood. I'm not against out-of-qtbase plugins. I am against forcing them
to use private and changing API like QtPlatformSupport.

Either way, we need to fix the linking. As I explained in more than one email,
as long as one big QtPlatformSupport library exists, we will have broken code.
Unless someone volunteers Ossi to somehow hack qmake to support this
behaviour.

And do it again once we switch buildsystems in Qt 5.1 or 5.2, since "mandatory
dependencies are optional" is not usually a feature.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] Qt Playground - Command Line Parser experiment

[Ariel Molina R.]

Hi,

Sounds great, Im using boost:program_options. I would help in testing
i dont really need boost.

Ariel


Ariel Molina Rueda



On Mon, Mar 12, 2012 at 9:53 AM, Christian Kandeler
 wrote:
> On 03/09/2012 12:36 AM, ext Laszlo Papp wrote:
>> I would like to experiment with a command line parser in Qt
>> Playground. The topic and the use case were more or less discussed
>> previously on the qt5-feedback mailing list around last October.
>>
>> It is not a separate module, but class(es). The name for this
>> experiment, in playground, would be something like "Command Line
>> Parser". According to the regulation: if nobody objects to this
>> addition from the beginning, I need to get the support of one existing
>> module maintainer in order to be able to experiment with this feature
>> in playground.
>>
>> Either way, please let me know your thoughts. Thank you in advance!
>
> After having written three project-specific command line parsers in as
> many months, I am enthusiastically in favor of having a general one in
> Qt. Definitely a good idea.
>
>
> Christian
> ___
> 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] QServiceClientCredentials

[Thomas Senyk]

On Monday, March 12, 2012 02:53:32 PM Blasche Alex wrote:
> Hi Thomas,
> 
> > -Original Message-
> > From: development-bounces+alex.blasche=nokia@qt-project.org
> > [mailto:development-bounces+alex.blasche=nokia@qt-project.org] On
> > 
> > What's up with the remote-service-cedentials?
> > It seams to be only part of the documentation, but no class, struct or
> > anything else in Qt5 QtLocation
> 
> The class is part of the Qt ServiceFramework module
> (qtsystems/src/serviceframework) and not the Qt Location module.

right, just a "typo" @ location 

And after doing the right grep I found it :) It's still called 
QRemoteServiceRegisterCredentials

... as it's called in the QtMobility code and doc, but it's call
QServiceClientCredentials
in the Qt5 doc.

Any reason for the mismatch?


> 
> --
> Alex
> 
> > It's still part of the documentation:
> > http://doc.qt.nokia.com/qt5/service-frameworks.html#service-security
> > 
> > 
> > Greets
> > Thomas
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Command Line Parser experiment

[Christian Kandeler]

On 03/09/2012 12:36 AM, ext Laszlo Papp wrote:
> I would like to experiment with a command line parser in Qt
> Playground. The topic and the use case were more or less discussed
> previously on the qt5-feedback mailing list around last October.
>
> It is not a separate module, but class(es). The name for this
> experiment, in playground, would be something like "Command Line
> Parser". According to the regulation: if nobody objects to this
> addition from the beginning, I need to get the support of one existing
> module maintainer in order to be able to experiment with this feature
> in playground.
>
> Either way, please let me know your thoughts. Thank you in advance!

After having written three project-specific command line parsers in as 
many months, I am enthusiastically in favor of having a general one in 
Qt. Definitely a good idea.


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

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

[Eric Wong]

Gunnar,

On Monday, March 12, 2012 11:25 PM, gunnar.sle...@nokia.com wrote:
> On Mar 12, 2012, at 3:35 PM, ext Eric Wong wrote:
>> Please consider to keep linuxfb platform plugin. There are still
>> many devices(e.g ARM9) that have no graphics accelerations at all
>> and there is only single process environment.
> Taking a plugin out of QtBase does not prevent it from flourishing in a 
> playgrounds repo or even in a supported qtlinuxfb repo when a maintainer for 
> it steps up. Right now, the reality is that many of these plugins are not 
> being looked after and they are therefore halfway broken.

Understood that the broken plugin should be removed in the imminent 
alpha stage.
I am not pushing developers to fix the plugin at the moment, but just 
hope to
have it included in final release. Thanks.

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

Re: [Development] Breaking up QtPlatformSupport

[gunnar.sletta]

On Mar 12, 2012, at 11:24 AM, ext Thiago Macieira wrote:

> On segunda-feira, 12 de março de 2012 09.31.11, Jørgen Lind wrote:
>>> This will be hard to do with qmake, so the easier way out is to remove the
>>> .a altogether and use .pri files only. That requires moving the Wayland
>>> platform plugin back into qtbase.
>> 
>> Pretty please with sugar on top, do NOT do this. I understand that you
>> only see the "Wayland" side of things, But there are loads of people
>> interested in not having their plugin in the Qt source code. Using the
>> pri approach is STUPID! The hacks you will force upon people is just
>> not nice! We have been there, and we don't want to go back. Lets just
>> keep/"add again" the -l flags, and let configure figure out if their going
>> to be included or not.
>> 
>> Building platform plugins outside the Qt source tree IS a usecase we'r
>> going to support. Not only because of QtWayland but because there might
>> be someone developing ie. an ios plugin that they don't want to have inside
>> QtBase. People might have special HW that where they just write a plugin
>> to do special ioctl to controll the display. We don't want all plugins to
>> be in QtBase but more importantly we can expect all plugins to be in
>> QtBase.
> 
> Building plugins outside of QtBase will continue to be permitted, provided 
> they don't use QtPlatformSupport. That library is just convenience for us. 
> There is absolutely no public API there. If there are things needed by many 
> plugins, we should consider making proper, public API instead.

Not only will building platform plugins outside QtBase be permitted, it will in 
fact be the primary usecase if we consider Qt's future on embedded devices. 
Most good adaptations will want to do something hardware specific. It is not 
just convenience for us inside QtBase.

We can talk about making it into a nicer API in a future version of Qt, but for 
Qt 5, we should keep it as it is. 

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

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

[gunnar.sletta]

On Mar 12, 2012, at 3:35 PM, ext Eric Wong wrote:
> Please consider to keep linuxfb platform plugin. There are still
> many devices(e.g ARM9) that have no graphics accelerations at all
> and there is only single process environment.

Taking a plugin out of QtBase does not prevent it from flourishing in a 
playgrounds repo or even in a supported qtlinuxfb repo when a maintainer for it 
steps up. Right now, the reality is that many of these plugins are not being 
looked after and they are therefore halfway broken. 

> I think it makes no sense to use eglfs/opengl which use software 
> rendering as backend on these devices.
> 
> I know we can use directfb or maybe wayland(there are wayland
> fbdev patches floating around) but fbdev is so slim and simple.
> 
> Most embedded system vendors do not deliver KMS driver, fbdev is still 
> de facto standard in low end devices at the moment.
> 
> I am looking forward to using QT5 and QPA with linux framebuffer support.
> 
> Thanks!
> 
> Eric
> 
> ___
> 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] License for QtSerialPort addon.

[Denis Shienkov]

Hi Marius, Lars, and all.

Tell me, please.
What type of license have addons that have been taken in the playground 
(Specifically interested in the type of license for QtSerialPort) ? 
You (Nokia) set its type, or I can assign a project of any type of licenses: 
BSD, MIT, etc. ?

Tell me specifically and accurately, and then there is a lot of confusion. :)

Best regards,
Denis

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

Re: [Development] Breaking up QtPlatformSupport

[Thiago Macieira]

On segunda-feira, 12 de março de 2012 15.23.33, Simon Hausmann wrote:
> The thing about platformsupport is that it is not a convenience library, it
> is at this moment absolutely essential for writing a real world platform
> plugin

That statement does not match the fact that it's a static lib with only
private headers.

As I said before, if this is essential, we should consider *proper* public
API. Keeping it like it is qualifies as "hack".

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] When to remove old platform plugins?

[Eric Wong]

Johannes,

On Monday, March 12, 2012 08:25 PM, Johannes Zellner wrote:
>> linuxfb:
>> Show case of Qt5/QWidgets in a single process environment?
> Having a very slim path for single process QWidget applications, which
> might find a usecase in the industrial areas would be nice.

+1

> But we have to be very clear then, otherwise people will try get
> scenegraph on that.

Noted, thanks.

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

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

[Eric Wong]

Dear all,

On Friday, March 09, 2012 04:21 AM, Holger Hans Peter Freyther wrote:
> Hi,
>
> the alpha is getting closer and we still have some QPA platform plugins that
> don't compile and I wonder what we should do with them? Polish and remove for
> Qt5 Alpha, leave it in and hope someone will pick them up?
>
> My list is:
>   - kms
>   - linuxfb
>   - openkode
>   - openvglite
>   - openwfd
>   - qvfb
>   - uikit
>   - vnc
>
> kms:
> Certainly a 'cool' plugin but is anyone using it? A platform that has KMS and
> Mesa can certainly support Wayland.
>
> linuxfb:
> Show case of Qt5/QWidgets in a single process environment?
>

Please consider to keep linuxfb platform plugin. There are still
many devices(e.g ARM9) that have no graphics accelerations at all
and there is only single process environment.

I think it makes no sense to use eglfs/opengl which use software 
rendering as backend on these devices.

I know we can use directfb or maybe wayland(there are wayland
fbdev patches floating around) but fbdev is so slim and simple.

Most embedded system vendors do not deliver KMS driver, fbdev is still 
de facto standard in low end devices at the moment.

I am looking forward to using QT5 and QPA with linux framebuffer support.

Thanks!

Eric

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

Re: [Development] Breaking up QtPlatformSupport

[Simon Hausmann]

On Monday, March 12, 2012 02:56:02 PM ext Thiago Macieira wrote:
> On segunda-feira, 12 de março de 2012 11.50.17, morten.sor...@nokia.com 
wrote:
> > On Mar 12, 2012, at 11:24 AM, ext Thiago Macieira wrote:
> > > Anyway, either way this library will be gone. The most likely solution
> > > is
> > > that we will break it up into many smaller .a libraries.
> > 
> > One other thing I've noticed is that linking agains an .a library breaks
> > incremental builds: touch qfontengine_coretext.mm, and the following
> > top-level build will not re-link the cocoa platform plugin.
> 
> That's not just Mac. It happens on all platforms.
> 
> qmake does not add a dependency on the .a file, so the other target doesn't
> get relinked.
> 
> > The best way to fix this seems to just include the relevant platform
> > support .pri files directly in the cocoa plugin (see
> > http://codereview.qt-project.org/#change,16107).
> 
> Which is what I'd prefer, but Jørgen is strongly against.
> 
> > Since nobody seems to want multiple .a files, what if we compromise and
> > allow both approaches? In-source platform plugins can use the .pri files
> > directly while out-of-source plugins link against libplatformsuppport.
> 
> It doesn't solve my problem. Those out-of-source plugins would not link
> properly.
> 
> The way I see it, our options are:
> 
> 1) do nothing (not an option, just for comparison)
>   => no plugins link properly
>   => relinking broken
> 
> 2) add the missing LIBS to platformsupport
>   => plugins link to libs they don't need
>   => relinking broken

The relinking could be fixed with POST_TARGETDEPS, here's what we use in WebKit 
to achieve the same:

win32-msvc*|wince*|win32-icc {
POST_TARGETDEPS += $${path}$${QMAKE_DIR_SEP}$${target}.lib
} else {
POST_TARGETDEPS += $${path}$${QMAKE_DIR_SEP}lib$${target}.a
}

The unnecessary linkage could be fixed by using an extra variable. For example
platformsupport.pri could include .pri files in all the modules and 
platformsupport.pro as well as the individual plugins using platformsupport 
could include platformsupport.pri.

Then for example the .pri file in the font-config platform font database could 
use PLATFORMLIBS += -lfontconfig

and the actual plugins do

LIBS += $$PLATFORMLIBS
 
> 3) break platformsupport into smaller libs
>   => lots of work
>   => links properly
>   => relinking still broken
> 
> 4) remove the libs completely
>   => links properly
>   => relinking fixed
>   => plugins outside of qtbase cannot use platformsupport

The thing about platformsupport is that it is _not_ a convenience library, it 
is at this moment absolutely _essential_ for writing a real world platform 
plugin ;(


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

Re: [Development] Breaking up QtPlatformSupport

[Thiago Macieira]

On segunda-feira, 12 de março de 2012 11.50.17, morten.sor...@nokia.com wrote:
> On Mar 12, 2012, at 11:24 AM, ext Thiago Macieira wrote:
> > Anyway, either way this library will be gone. The most likely solution is
> > that we will break it up into many smaller .a libraries.
>
> One other thing I've noticed is that linking agains an .a library breaks
> incremental builds: touch qfontengine_coretext.mm, and the following
> top-level build will not re-link the cocoa platform plugin.

That's not just Mac. It happens on all platforms.

qmake does not add a dependency on the .a file, so the other target doesn't get
relinked.

> The best way to fix this seems to just include the relevant platform support
> .pri files directly in the cocoa plugin (see
> http://codereview.qt-project.org/#change,16107).

Which is what I'd prefer, but Jørgen is strongly against.

> Since nobody seems to want multiple .a files, what if we compromise and
> allow both approaches? In-source platform plugins can use the .pri files
> directly while out-of-source plugins link against libplatformsuppport.

It doesn't solve my problem. Those out-of-source plugins would not link
properly.

The way I see it, our options are:

1) do nothing (not an option, just for comparison)
=> no plugins link properly
=> relinking broken

2) add the missing LIBS to platformsupport
=> plugins link to libs they don't need
=> relinking broken

3) break platformsupport into smaller libs
=> lots of work
=> links properly
=> relinking still broken

4) remove the libs completely
=> links properly
=> relinking fixed
=> plugins outside of qtbase cannot use platformsupport

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] QServiceClientCredentials

[alex.blasche]

Hi Thomas,

> -Original Message-
> From: development-bounces+alex.blasche=nokia@qt-project.org
> [mailto:development-bounces+alex.blasche=nokia@qt-project.org] On

> What's up with the remote-service-cedentials?
> It seams to be only part of the documentation, but no class, struct or
> anything else in Qt5 QtLocation

The class is part of the Qt ServiceFramework module 
(qtsystems/src/serviceframework) and not the Qt Location module. 

--
Alex

> It's still part of the documentation:
> http://doc.qt.nokia.com/qt5/service-frameworks.html#service-security
> 
> 
> Greets
> Thomas
> ___
> 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] QServiceClientCredentials

[Thomas Senyk]

What's up with the remote-service-cedentials?
It seams to be only part of the documentation, but no class, struct or 
anything else in Qt5 QtLocation

It's still part of the documentation:
http://doc.qt.nokia.com/qt5/service-frameworks.html#service-security


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

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

[morten.sorvig]

On Mar 12, 2012, at 1:25 PM, ext Johannes Zellner wrote:

> On 03/08/2012 09:21 PM, ext Holger Hans Peter Freyther wrote:
>> uikit:
>> There was no development of the plugin in Qt5.
> Is anybode using them on Qt5? or even tried to use them?

I believe uikit may be revived for Qt5, please hold off on removing it for now.

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

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

[Johannes Zellner]

On 03/08/2012 09:21 PM, ext Holger Hans Peter Freyther wrote:
> Hi,
>
> the alpha is getting closer and we still have some QPA platform plugins that
> don't compile and I wonder what we should do with them? Polish and remove for
> Qt5 Alpha, leave it in and hope someone will pick them up?
At the moment some of the platform plugins simply are broken or missing 
some stuff in for example the eglconvenience or fb_base.
So for the alpha release we should either have them fixed or 
removed...running configure and seeing errors for parts that are not 
tested and known to be broken is not very nice.
> linuxfb:
> Show case of Qt5/QWidgets in a single process environment?
Having a very slim path for single process QWidget applications, which 
might find a usecase in the industrial areas would be nice.
But we have to be very clear then, otherwise people will try get 
scenegraph on that.

> openkode:
> Dead specification?
>
> openvglite:
> ???
>
> openfwd:
> ???
>
> qvfb:
> QWS is dead.. is there any reason to have this around?
>
> uikit:
> There was no development of the plugin in Qt5.
Is anybode using them on Qt5? or even tried to use them?

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

Re: [Development] Breaking up QtPlatformSupport

[morten.sorvig]

On Mar 12, 2012, at 11:24 AM, ext Thiago Macieira wrote:
Anyway, either way this library will be gone. The most likely solution is that
we will break it up into many smaller .a libraries.

One other thing I've noticed is that linking agains an .a library breaks 
incremental builds: touch qfontengine_coretext.mm, and the following top-level 
build will not re-link the cocoa platform plugin.

The best way to fix this seems to just include the relevant platform support 
.pri files directly in the cocoa plugin (see 
http://codereview.qt-project.org/#change,16107).

Since nobody seems to want multiple .a files, what if we compromise and allow 
both approaches? In-source platform plugins can use the .pri files directly 
while out-of-source plugins link against libplatformsuppport.

Morten

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

[Development] QUuid changes

[Denis Dzyubenko]

Hi,

There is a change that I was working that that slipped out of my hands
and was left unnoticed on gerrit (thanks Robin for reminding me!)

Is it too late to integrate a patch that removes implicit conversion
between QUuid and Windows GUID struct?
http://codereview.qt-project.org/11968

I would also like to remove other implicit conversions, like the
following constructors:

QUuid(const QString &);
QUuid(const char *);
QUuid(const QByteArray &);

remove them in favor of using explicit conversion functions
QUuid::toString and QUuid::fromString (see
http://codereview.qt-project.org/19580 )

If not removing, then at least make those constructors explicit to
avoid unintentional expensive conversions being used in applications.

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

Re: [Development] Breaking up QtPlatformSupport

[Thiago Macieira]

On segunda-feira, 12 de março de 2012 09.31.11, Jørgen Lind wrote:
> > This will be hard to do with qmake, so the easier way out is to remove the
> > .a altogether and use .pri files only. That requires moving the Wayland
> > platform plugin back into qtbase.
>
> Pretty please with sugar on top, do NOT do this. I understand that you
> only see the "Wayland" side of things, But there are loads of people
> interested in not having their plugin in the Qt source code. Using the
> pri approach is STUPID! The hacks you will force upon people is just
> not nice! We have been there, and we don't want to go back. Lets just
> keep/"add again" the -l flags, and let configure figure out if their going
> to be included or not.
>
> Building platform plugins outside the Qt source tree IS a usecase we'r
> going to support. Not only because of QtWayland but because there might
> be someone developing ie. an ios plugin that they don't want to have inside
> QtBase. People might have special HW that where they just write a plugin
> to do special ioctl to controll the display. We don't want all plugins to
> be in QtBase but more importantly we can expect all plugins to be in
> QtBase.

Building plugins outside of QtBase will continue to be permitted, provided
they don't use QtPlatformSupport. That library is just convenience for us.
There is absolutely no public API there. If there are things needed by many
plugins, we should consider making proper, public API instead.

Anyway, either way this library will be gone. The most likely solution is that
we will break it up into many smaller .a libraries.

Adding -l flags does not work because of the way qmake works. When you write:

QT += platformsupport-private
LIBS += -lfoo

or when you write:

LIBS += -lfoo
QT += platformsupport-private

This will always add to the command line:

-lfoo -lQtPlatformSupport

which is the wrong order. It needs to be the other way around.

Writing:

LIBS += -lQtPlatformSupport -lfoo
QT += platformsupport-private

produces:

-lQtPlatformSupport -lfoo -lQtPlatformSupport

which is even worse: not only does it not solve anything, it's wrong by not
adding the proper library infix, version or debug status.

As far as I can see, there's no way to do that with standard qmake options.
We'd need to remove the library from "QT", which means we lose the -I
(include) options too.

And before anyone suggests "fixing the bug" note where the bug is: it is NOT a
bug in qmake. The bug is that QtPlatformSupport fails to declare the libraries
that it requires, so qmake cannot add them properly.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1

[Kent Hansen]

Hi,
qtdeclarative needs to be adapted to some recent changes in qtbase. 
While we try to get that done 
(http://codereview.qt-project.org/#change,18941), staging of unrelated 
changes to qtdeclarative has been blocked.

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

Re: [Development] Breaking up QtPlatformSupport

[lars.knoll]

On 3/12/12 9:31 AM, "ext Jørgen Lind"  wrote:

>> This will be hard to do with qmake, so the easier way out is to remove
>>the .a 
>> altogether and use .pri files only. That requires moving the Wayland
>>platform 
>> plugin back into qtbase.
>> 
>Pretty please with sugar on top, do NOT do this. I understand that you
>only see the "Wayland" side of things, But there are loads of people
>interested in not having their plugin in the Qt source code. Using the
>pri approach is STUPID! The hacks you will force upon people is just
>not nice! We have been there, and we don't want to go back. Lets just
>keep/"add again" the -l flags, and let configure figure out if their going
>to be included or not.
>
>Building platform plugins outside the Qt source tree IS a usecase we'r
>going to support. Not only because of QtWayland but because there might
>be someone developing ie. an ios plugin that they don't want to have
>inside
>QtBase. People might have special HW that where they just write a plugin
>to do special ioctl to controll the display. We don't want all plugins to
>be in QtBase but more importantly we can expect all plugins to be in
>QtBase.

I have to agree with Joergen. We simply can't expect all platform plugins
to live in QtBase. 

I also agree that we need a fix for plugins having undefined symbols, but
we'll have to find a different way that forcing everything to live in
qtbase.

Cheers,
Lars

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

Re: [Development] Breaking up QtPlatformSupport

[Jørgen Lind]

> This will be hard to do with qmake, so the easier way out is to remove the .a 
> altogether and use .pri files only. That requires moving the Wayland platform 
> plugin back into qtbase.
> 
Pretty please with sugar on top, do NOT do this. I understand that you
only see the "Wayland" side of things, But there are loads of people
interested in not having their plugin in the Qt source code. Using the
pri approach is STUPID! The hacks you will force upon people is just
not nice! We have been there, and we don't want to go back. Lets just
keep/"add again" the -l flags, and let configure figure out if their going
to be included or not.

Building platform plugins outside the Qt source tree IS a usecase we'r
going to support. Not only because of QtWayland but because there might
be someone developing ie. an ios plugin that they don't want to have inside
QtBase. People might have special HW that where they just write a plugin
to do special ioctl to controll the display. We don't want all plugins to
be in QtBase but more importantly we can expect all plugins to be in
QtBase.

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

Re: [Development] Breaking up QtPlatformSupport

[Oswald Buddenhagen]

On Sun, Mar 11, 2012 at 05:59:16PM +0100, ext Thiago Macieira wrote:
> This will be hard to do with qmake, so the easier way out is to remove the .a 
> altogether and use .pri files only.
> 
well, there is also the option to split it into multiple .a files which
have their own dependency lists. the increasingly "lump" approach of
that library doesn't look very elegant anyway.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Quick in Qt 5 is sluggish and other observations

[Oswald Buddenhagen]

On Sun, Mar 11, 2012 at 09:57:12AM -0600, ext Ariel Molina R. wrote:
> First observation:
> It did not install qtdeclarative, i had to manually go in and make install
> 
this is being worked on.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] On qbs use inside Qt

[Oswald Buddenhagen]

On Sun, Mar 11, 2012 at 08:11:09PM +0100, ext Stephen Kelly wrote:
> I notice that several repos (I didn't look at all) contain a buildsystem 
> branch. Is this what that is for?
> 
no, that's for my qmake/configure work for 5.0. we noticed that pretty
much every change to qmake breaks *something* (predominantly outside
qtbase), so we got a bit defensive.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Quick2 OpenGL or Raster translucent window

[gunnar.sletta]

On Mar 12, 2012, at 5:31 AM, ext hailong geng wrote:

> Hi
>   Yes, I have tried this before and only get black background. 
>   I have reported a bug : 
> https://bugreports.qt-project.org/browse/QTBUG-24707 (I am not sure whether 
> this should be a bug or a task).
>   I just want to make QQuickView with translucent bakcground work(with 
> OpenGL as backend is the best but Raster is also ok). 

QQuickView's will only ever use OpenGL as the whole graphics stack for QML 2 is 
built on top of OpenGL. Raster is not an option.

>   Because windows XP doesn't support pixel alpha blending with OpenGL so 
> maybe we can't make QQuickView work translucently in Xp with OpenGL backend, 
> but we can do that in Vista or win7 Using dwmapi.dll to support that. 
>   I am not familiar with the new QQuickView structure, so I don't know 
> what is the best way to make QQuickView with translucent background work in 
> Win7 and Xp(with OpenGL the best), may you tell me what should I do or 
> forward this question to some person who is in charge of QQuickView and Scene 
> Graph?

There are several places the translucency can go wrong. 

- Does OpenGL with alpha work for Qt at all on Win7? Can be tested with a 
QWindow / QOpenGLContext with a minimal glClear() / swapBuffers(). If this does 
not work, then the problem is in the windows platform plugin.
- The scene graph renderer will clear the color buffer with 
QQuickCanvas::clearColor() which is opaque white by default.
- The QQuickView might put an opaque fullscreen rectangle into the scene, so 
even if you have alpha support on the QWindow / QOpenGLContext layer, you would 
still need to avoid opaque stuff in the scenegraph. 

To make the GL integration on windows as good as any DirectX integration, we 
wanted to try out layering our GL code on top of ANGLE 
(http://code.google.com/p/angleproject/) so we would be calling GL api but 
using DirectX under the hood. I don't think anybody tried this yet, but if 
you're up for it, I would be interested in hearing the outcome :)

Hope this helps you dig a bit further.

cheers,
Gunnar

>   Thank you^_^
> 
> From: "sarah.j.sm...@nokia.com" 
> To: longlon...@yahoo.com 
> Cc: samuel.ro...@nokia.com; development@qt-project.org 
> Sent: Sunday, March 11, 2012 5:32 PM
> Subject: Re: [Development] Qt Quick2 OpenGL or Raster translucent window
> 
> Hi
> 
> Have you tried something like this:
> 
> int main(int argc, char *argv[])
> {
> QGuiApplication app(argc, argv); 
> QSurfaceFormat f;
> f.setSamples(16);  // if you want AA as well
> f.setAlphaBufferSize(8);   // turn on alpha
> QQuickView view;
> view.setFormat(f);
> view.setSource(QUrl::fromLocalFile(QLatin1String("/path/to/my.qml"));
> view.show();
> return app.exec();
> }
> 
> I don't have a windows box handy to try this on, but give it a try.
> 
> As far as I know qmlscene doesnt know how to run with an alpha enabled GL 
> context.
> 
> Regards
> 
> Sarah Smith
> Senior Engineer Team Lead Qt3D
> Nokia Qt Development Frameworks
> Mobile: +61 448 283 476
> sarah.j.sm...@nokia.com
> 
> 
> 
> On 11/03/2012, at 3:13 AM, ext hailong geng wrote:
> 
>> Hi
>> I have searched the Internet these two days and I find that it seems 
>> impossible to draw translucent window in Windows XP by OpenGL, because it 
>> doesn't support pixel alpha blending. So does Qt have found a way to do that 
>> for Windows XP? 
>> Or Qt Quick2 just ignore the translucent function for Window which use 
>> OpenGL as backend, or even with Raster backend, I tried to set alpha channel 
>> and  use  RasterSurface but QQuickView just crashed.(maybe  RasterSurface  
>> backend is not finished?)
>> 
>> For Windows Vista and newer windows version, there is DWMAPI which will 
>> support translucent opengl on desktop, you can see this demo, 
>> http://www.youtube.com/watch?v=4qWKSYWIqdk, this is cool, isn't it ^_^
>> So shall Qt support translucent OpenGL window for Windows Vista and any 
>> newer version?
>> ___
>> 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