Re: [Development] Towards a Qt 5 beta: Documentation
On 4/13/12 7:34 AM, Lincoln Ramsay lincoln.ram...@nokia.com wrote: On 04/13/2012 03:19 PM, Vandonderen Casper (Nokia-MP/Oslo) wrote: But I would be grateful if you would make a plan on how to turn qdoc into a mini-qmake so that qdoc can parse the .pro/sync.profile, so that we don't need the depends. Because that would probably also mean that you have to run qdoc [module.pro] [module.qdocconf], or do you see that differently? Doesn't qmake run over doc.pri to generate a Makefile rule make docs that you run? Or are we moving away from make docs and towards running qdoc explicitly? You are correct, that is what will happen, the same as the current system. The thing is that people have difficulty understanding where QT_QML_QDOCCONF etc. come from currently. I can see a problem with this since for Qt QtCore is just called core, and I would not want to output the documentation to just /doc/core, but /doc/qtcore, since there might be modules that do not start with Qt and still use QDoc. Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta: Documentation
On 4/13/12 10:32 AM, ext Oswald Buddenhagen
oswald.buddenha...@nokia.com wrote:
On Fri, Apr 13, 2012 at 07:04:42AM +, ext
casper.vandonde...@nokia.com wrote:
You are correct, that is what will happen, the same as the current
system.
The thing is that people have difficulty understanding where
QT_QML_QDOCCONF etc. come from currently.
I can see a problem with this since for Qt QtCore is just called core,
and
I would not want to output the documentation to just /doc/core, but
/doc/qtcore, since there might be modules that do not start with Qt and
still use QDoc.
big deal.
qdoc_deps =
for(m, QT): qdoc_deps += $$lower($$eval(QT.$${m}.name))
and all that should be centralized in qt_module_config.prf, where all
the module creation magic happens. a lot more is already pending for the
buildsystem branch.
you should ask the buildsystem guys a bit more often in advance instead
of complaining that they are complaining about your solutions. ;)
Ok, that will work for Qt C++ modules. If a user has a QML-only module we
still need to hard-code it in the .pri file then.
Casper
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Resolving the wiki situtation
Hello! I assume everyone is aware of the current situation of us having two different wikis: one at wiki.qt-project.org and one at qt-project.org/wiki. It was never planned to happen that way, but sometimes plans don't really work out the way I think. :P Anyway, the current situation is stupid, and I have a plan to fix it. Starting from Thursday next week, we will copy the pages that currently live on wiki.qt-project.org over to qt-project.org/wiki, below the Developing Qt category. It's not the perfect way of doing things but after long discussions, we agreed that it is the most pragmatic. So. If you currently have pages in the making that haven't hit the wiki yet, please create them on qt-project.org/wiki to spare us extra work. If you have pages that you really care about being associated with your name, you should probably move them yourself. :) Let me know if you have any questions. Cheers, Alex -- Alexandra Leisse Web Usability Specialist ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Multiseat capability to Qt
Hello all,
after doing some small fixes to KMS QPA plugin, I proceeded with
implementing the input device support via evdev. It was soon pointed out
that perhaps using the generic evdev plugins would be better idea. I
experimented with them a bit and seems they need some work.
Specifically, all these plugins generate the events via
QWindowSystemInterface::handle{Key,Mouse}Event, with the first parameter
being set to null. Same applies to handleTouchEvent, but touch handling
is a bit more hairy so let's skip it for the sake of clarity.
Looking at QGuiApplicationPrivate::processKeyEvent reveals that for KMS
the key event is always discarded and in processMouseEvent the event
gets delivered to first available screen in practice.
Currently the KMS QPA plugin works with multiple screens and I would
like to assign the input devices to these screens via the ID_SEAT
attribute in the udev database. In other words, a screen and a number of
input devices like keyboards and mouses would be bound into a single
seat. This would also solve my problem; the evdev plugins could be
modified to send the events to the toplevel window associated with the
given screen (which in turn is associated to the given input device).
I'm inclined towards adding a new interface to QPA API, namely
QPlatformSeat. The platform plugins could implement their own grouping
for the screen and the input devices.
Any comments?
--
Hannu Lyytinen
Senior Software Developer, Nomovok Ltd
email: hannu.lyyti...@nomovok.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposed API change: Change signature of QMessageHandler to use QString
-Original Message- From: Beck Wolfgang (Nokia-MP/Brisbane) Sent: Friday, April 13, 2012 1:23 AM To: Koehne Kai (Nokia-MP/Berlin); thiago.macie...@intel.com; development@qt-project.org Subject: RE: [Development] Proposed API change: Change signature of QMessageHandler to use QString Before I would do such a change I would check if there are other projects in QT they install their own messaghandler. I think they all need to change their code as well. Maybe we should keep it as it is. Well, I'd like not to add a '//Qt6: Fix' comment at this point in time already ;) But I'm now trying to keep the old API working for a transition period by adding a 'QtMessageHandler' instead of just changing 'QMessageHandler': https://codereview.qt-project.org/#change,22151 . The only breakage this will cause is for apps that call 'qInstallMessageHandler(0)'. Regards Kai Cheers, WB -Original Message- From: development-bounces+wolfgang.beck=nokia@qt-project.org [mailto:development-bounces+wolfgang.beck=nokia@qt-project.org] On Behalf Of Koehne Kai (Nokia-MP/Berlin) Sent: Friday, April 13, 2012 12:41 AM To: thiago.macie...@intel.com; development@qt-project.org Subject: Re: [Development] Proposed API change: Change signature of QMessageHandler to use QString -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of ext Thiago Macieira Sent: Thursday, April 12, 2012 3:14 PM To: development@qt-project.org Subject: Re: [Development] Proposed API change: Change signature of QMessageHandler to use QString On quinta-feira, 12 de abril de 2012 08.17.37, kai.koe...@nokia.com wrote: Hi, I'd like to get https://codereview.qt-project.org/#change,22151,patchset=5 into 5.0/api_changes branch. It's one more change to the logging framework, specifically to the signature of QMessageHandler (new in 5.0, old QtMsgHandler is unchanged): void (*QMessageHandler)(QtMsgType, const QMessageLogContext , const char *); becomes void (*QMessageHandler)(QtMsgType, const QMessageLogContext , const QString ); Maybe QChar *begin, int len? Or QChar *begin, guaranteed to be NUL-terminated? What's the advantage of having a QChar * in contrast to a QString? The reason is to avoid unnecessary string conversions, especially on Windows. E.g. qDebug() Hello World; will right now result in const char * - QString conversion in QDebug::operator(const char *) (QString::fromAscii(), shouldn't this be QString::fromLatin1() btw?) fromAscii() was correct in the sense of from whatever the user used in developing source code. Just realized that nowadays fromAscii==fromLatin1. So it's really just a matter of taste. QString - const char * conversion in QDebug::~QDebug() (QString::toLocal8Bit()) const char *- QByteArray conversion in qMessageFormatString() for the default message handler a QByteArray - QString conversion in qWinMessageHandler() (QString::fromLocal8Bit) So we're converting from latin1 to utf16 to local8bit to utf16 :) The patch mitigates this somewhat by passing const QString as argument to the message handler, instead of const char *. I support this. The message handler is new API and this change is not changing compatibility with Qt 4. I assume you will do a final UTF16-to-local8bit if the user installed a legacy 8- bit message handler. Yes, that's already part of the patch. [...] -- 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 ___ 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] Multiseat capability to Qt
On 04/13/2012 11:37 AM, ext Hannu Lyytinen wrote:
Hello all,
after doing some small fixes to KMS QPA plugin, I proceeded with
implementing the input device support via evdev. It was soon pointed out
that perhaps using the generic evdev plugins would be better idea. I
experimented with them a bit and seems they need some work.
Specifically, all these plugins generate the events via
QWindowSystemInterface::handle{Key,Mouse}Event, with the first parameter
being set to null. Same applies to handleTouchEvent, but touch handling
is a bit more hairy so let's skip it for the sake of clarity.
Looking at QGuiApplicationPrivate::processKeyEvent reveals that for KMS
the key event is always discarded and in processMouseEvent the event
gets delivered to first available screen in practice.
Currently the KMS QPA plugin works with multiple screens and I would
like to assign the input devices to these screens via the ID_SEAT
attribute in the udev database. In other words, a screen and a number of
input devices like keyboards and mouses would be bound into a single
seat. This would also solve my problem; the evdev plugins could be
modified to send the events to the toplevel window associated with the
given screen (which in turn is associated to the given input device).
I'm inclined towards adding a new interface to QPA API, namely
QPlatformSeat. The platform plugins could implement their own grouping
for the screen and the input devices.
Any comments?
Isn't this just a question of the platform plugin delivering a given
input event to the correct window? What API did you have in mind for
QPlatformSeat in relation to QPlatformScreen and input handling?
Speaking about the generic evdev plugins, maybe we should enable them to
both be stand-alone as they currently are, or to be compiled into the
platform plugin itself for greater control. That way most of the code
could be shared, and the evdev plugins could act either as helper
libraries or as generic plugins.
--
Samuel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
I've grepped through all the modules to create a list of these insignificant tests, and listed them below. Please note that a test marked as insignificant in essence provides us with zero coverage, since all results from those test cases (although run) are completely ignored. IMO, if there are tasks we cannot repair, due to the tests being inheritly unstable, or our infrastructure not being able to handle it, then we should remove them. Having test cases which adds no value, but is hard to see unless you find the insignificant_test keyword, is bad since you don't know exactly what the coverage is and where it is lacking. I agree that having useless tests adds no value. From my examination of the insignificant tests so far, I would say that most of them should be able to be fixed rather than discarded. I have also noticed that some other tests are disabled by removing them from SUBDIRS in their parent directory .pro file. Sometimes this is legitimate (test doesn't apply to a particular platform or build config), but sometimes they are disabled this way because the test is/was broken. The result is effectively the same as marking the test insignificant, but it's much harder to grep for. so please avoid this practice in future and use insignificant_test instead. It may be a while before I can find time to investigate these properly, so any help would be appreciated. How should we mark that we are working on a specific test case to fix the instability etc, to ensure we don't do double work? Suggestions? Is a Jira task with 'module: insignificant test name' good enough? I am currently going through all of the insignificant tests that have no associated bug report and creating appropriate Jira tasks with suggestions for how to proceed based on analysis of recent CI logs. This analysis is proving to be rather time consuming, but shows that a lot of the insignificant_test markers could be replaced by QEXPECT_FAIL calls because a lot of the insignificant test appear to be failing in a consistent fashion (at least over the last ten CI runs). Some trivial commits to add the bug numbers next to the insignificant_test markers will filter through the CI system over the next few days, which should cure any worries about doing duplicate work as every insignificant_test marker in Qt will have a bug number next to it. I'm happy to be added to gerrit reviews for anyone fixing insignificant tests and also to try to provide further advice on ways to fix specific insignificant tests. -- Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
Another way tests have been disabled is using CONFIG += no_check_target which seems to have been done when tests were initially disabled before the insignificant_test option was added. Actually, I think that came a little later (when the refactor branch was merged into master). That mechanism was added to disable a whole subtree of tests/auto rather than marking every individual test in the subtree as insignificant one at a time. This allowed the CI system to start running and enforcing some of the Mac tests again after it had been pretty much all broken. Brad Hughes has been working on fixing tests on Mac since then and the current results are a huge improvement from where they were last August when refactor was merged and the CI system wasn't able to run any tests on Mac at all. (Thanks Brad!) Any help we can get from the community to fix/re-enable the remaining disabled tests on Mac would be much appreciated. -- Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
Random question of the day: do you happen to have stats about how often those insignificant tests actually fail? That should help to figure out which ones are actually working, and therefore should not be marked as insignificant. -- Giuseppe D'Angelo The CI logs are publicly available, but are huge in size. I've been using the attached perl script to run tests repeatedly before removing insignificant_test. e.g. ~/test100.pl -c=250 -- ./tst_x -silent -- 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 test100.pl Description: test100.pl ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt5 + NX
Hi all,
When testing Qwt with Qt5 I was running a NX ( http://www.nomachine.com
) remote desktop. Local was a SuSE/Linux 11.2, remote ran a SuSE 12.1/Linux.
With about half of the Qwt applications I had the following effect: as
soon as I move the mouse over the application window ( Xfce4, focus
follow mouse is enabled ) inside the remote desktop the complete screen
on my local system ( the local desktop ! ) is black. When I move the
mouse out of the window the screen is o.k. again. Doing all the same
with Qt 4.8.0 or running the applications with Qt5 and X11 remote
doesn't show any problem.
Bugs like these are really hard to reproduce - too many candidates to be
responsible - but if someone is interested in investigations let me know.
Uwe
Below is a small demo showing the effect on my box.
---
#include qapplication.h
#include qmainwindow.h
#include qtoolbar.h
#include qtoolbutton.h
#include qlayout.h
class MainWindow: public QMainWindow
{
public:
MainWindow()
{
QWidget *w = new QWidget( this );
QHBoxLayout *layout = new QHBoxLayout( w );
layout-addWidget( new QWidget() );
setCentralWidget( w );
QToolBar *toolBar = new QToolBar( this );
QToolButton *button = new QToolButton();
toolBar-addWidget( button );
addToolBar( toolBar );
}
};
int main( int argc, char **argv )
{
QApplication a( argc, argv );
MainWindow w;
w.resize( 600, 400 );
w.show();
return a.exec();
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Resolving the wiki situtation
On Fri, Apr 13, 2012 at 8:57 AM, marius.storm-ol...@nokia.com wrote: On 13/04/2012 08:50, ext Girish Ramakrishnan wrote: On Fri, Apr 13, 2012 at 1:56 AM,alexandra.lei...@nokia.com wrote: Starting from Thursday next week, we will copy the pages that currently live on wiki.qt-project.org over to qt-project.org/wiki, below the Developing Qt category. It's not the perfect way of doing things but after long discussions, we agreed that it is the most pragmatic. Will the old pages redirect to the new one or will the domain wiki.qt-project.org completely die after thursday? Ideally former since we have lots of pages in wiki.qt-project.org but I can live with the fact that it will completely die. I had also suggested that we make wiki.qt-project.org read-only to Quim. Do you think we can just lock it starting this weekend? Ideally I would want wiki.qt-project.org to point to the valid wiki (which is now at qt-project.org/wiki). I really don't think we should spend time and effort keeping backwards compatibility with the old wiki entries. I was hoping we could have a simple url rewrite, but I agree no more effort. Some of our pages (like devices - http://wiki.qt-project.org/Devices which went out in yesterday's blog post) will all be broken. But as I said, I can live with that :) Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Multiseat capability to Qt
On Fri, Apr 13, 2012 at 3:20 AM, Samuel Rødal samuel.ro...@nokia.com wrote:
On 04/13/2012 11:37 AM, ext Hannu Lyytinen wrote:
Hello all,
after doing some small fixes to KMS QPA plugin, I proceeded with
implementing the input device support via evdev. It was soon pointed out
that perhaps using the generic evdev plugins would be better idea. I
experimented with them a bit and seems they need some work.
Specifically, all these plugins generate the events via
QWindowSystemInterface::handle{Key,Mouse}Event, with the first parameter
being set to null. Same applies to handleTouchEvent, but touch handling
is a bit more hairy so let's skip it for the sake of clarity.
Looking at QGuiApplicationPrivate::processKeyEvent reveals that for KMS
the key event is always discarded and in processMouseEvent the event
gets delivered to first available screen in practice.
Currently the KMS QPA plugin works with multiple screens and I would
like to assign the input devices to these screens via the ID_SEAT
attribute in the udev database. In other words, a screen and a number of
input devices like keyboards and mouses would be bound into a single
seat. This would also solve my problem; the evdev plugins could be
modified to send the events to the toplevel window associated with the
given screen (which in turn is associated to the given input device).
I'm inclined towards adding a new interface to QPA API, namely
QPlatformSeat. The platform plugins could implement their own grouping
for the screen and the input devices.
Any comments?
Isn't this just a question of the platform plugin delivering a given
input event to the correct window? What API did you have in mind for
QPlatformSeat in relation to QPlatformScreen and input handling?
Speaking about the generic evdev plugins, maybe we should enable them to
both be stand-alone as they currently are, or to be compiled into the
platform plugin itself for greater control. That way most of the code
could be shared, and the evdev plugins could act either as helper
libraries or as generic plugins.
Agree with Samuel here. The input plugins can be made smart enough to
iterate through the screen list and locate the correct target window.
Currently, the generic plugins are used only by eglfs which only has
one window and as a result passing 0 as window argument worked fine.
Girish
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Resolving the wiki situtation
On 13/04/2012 11:03, ext Girish Ramakrishnan wrote: On Fri, Apr 13, 2012 at 8:57 AM,marius.storm-ol...@nokia.com wrote: On 13/04/2012 08:50, ext Girish Ramakrishnan wrote: On Fri, Apr 13, 2012 at 1:56 AM,alexandra.lei...@nokia.com wrote: Will the old pages redirect to the new one or will the domain wiki.qt-project.org completely die after thursday? Ideally former since we have lots of pages in wiki.qt-project.org but I can live with the fact that it will completely die. I had also suggested that we make wiki.qt-project.org read-only to Quim. Do you think we can just lock it starting this weekend? Ideally I would want wiki.qt-project.org to point to the valid wiki (which is now at qt-project.org/wiki). I really don't think we should spend time and effort keeping backwards compatibility with the old wiki entries. I was hoping we could have a simple url rewrite, but I agree no more effort. Some of our pages (like devices - http://wiki.qt-project.org/Devices which went out in yesterday's blog post) will all be broken. But as I said, I can live with that :) Ok, the messaging since we got both wikis is that the old wiki will die and to use the new wiki from that day on. :) Just copy the content over to the new wiki, and update the blog post. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fixing the DLL/shared/static mess
On sexta-feira, 13 de abril de 2012 13.41.34, Thiago Macieira wrote: I ran into Ossi and Marius S.O. talking about the mess we have with the build and use of Qt as shared/DLL or static. It's something I had begun fixing, but I haven't finished yet. If you're dealing with a different buildsystem than qmake, or you're packaging Qt, please my email that is a reply to this: The word read in please read my email was missing. 4) Packagers who package only one type of Qt build (shared or static, but not both), should not see any changes either. One Qt build means a set of library files and the headers (e.g.: libQtCore.so and qconfig.h). THIS IS A PROPOSAL A static-and-shared build of Qt is currently not supported. There are no plans to accomplish this with the current buildsystem in one build. However, it might be possible to do it in two builds. If you want to try this, the recommendation is: 1) configure Qt for shared 2) build and install all libs and headers, including qconfig.h, qconfig.pri 3) configure Qt for static 4) build but install *only* the library files; do NOT overwrite qconfig.h 5) report back to the mailing list because we need the feedback ASSUMPTION: you *can* have both sets of libraries installed in the same place and your linker will link to the shared Qt if no extra command-line options are passed. On Windows, since linking to a DLL actually links to a static import library, the above is not possible. Buildsystems should be changed to support compile-time selection of which one to link to. For qmake, the proposed solution is: CONFIG += prefer_shared_qt CONFIG += prefer_static_qt prefer_shared_qt is a no-op, since it's the default prefer_static_qt defines QT_STATIC and must also use a static linking form: -static -lQtQml -lQtGui -lQtCore -shared $dependent_libs The dependent libs need to be read from each lib's .prl file LIBS_PRIVATE variable (currently not set). -- 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] Resolving the wiki situtation
I do propose that we freeze http://wiki.qt-project.org/ giving editing permissions only to http://wiki.qt-project.org/index.php?title=Special:ListUsersgroup=sysop and seting a deprecation period of 6? months. At the date agreed the wiki would be switched off. In the meantime the pages that matter can be soft redirected e.g. http://wiki.qt-project.org/Events/Qt_Contributors_Summit On 04/13/2012 09:19 AM, ext marius.storm-ol...@nokia.com wrote: Just copy the content over to the new wiki, and update the blog post. Not that trivial with a page like http://wiki.qt-project.org/QtonPi/Device_program/Accepted - a page started well before a new wiki was in the horizon. Or http://wiki.qt-project.org/QtonPi - a URL that is now in many places, most of us not controlled by us. Don't get me wrong. I'm all fine in having just one wiki. It's just that it takes some time to move content properly. Before moving all the QtonPi pages I'd like to check with the QtonPi developers (hundreds) what is the best next step forward. For instance, a DevNet group comes to mind. -- Quim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] api changes
On 04/13/2012 07:08 PM, ext Girish Ramakrishnan wrote: Hi, I am going through all the new apis. I have a couple of more changes to the public apis already. I am not submitting them to api_changes branch. I think Lars and co are having enough trouble as-is with getting api_changes to merge to master :-) All the commits will have the api: prefix in the commit message (so it's easy to see on my dashboard). I will stage them only after api_changes is merged. My current understanding of the qpa plan is this, correct me if I am wrong: 1. Files with _qpa in them are supposed to be used by plugins and plugins only. If you see, _qpa.h being used in application code, they are using a binary and source incompatible Qt. _qpa.h also lacks the 'we mean it' header which I will add. Mostly, though I guess an application might use QPlatformNativeInterface to get access to a platform specific resource (such as the X display or the wayland display or window handles etc). Maybe we'll need to make a public API front-end for that down the line. 2. No public Qt include files should have _qpa.h in them 3. _qpa.h files are installed only so that we can allow development of plugins outside of qt source. I would like to see them not getting installed at all but I don't know if this is an oversight or intentional. 4. Also, I would like to see all the handle() functions in public api die. Or make them protected and make all the classes friends (as such they are all mostly friends anyway). handle() encourages writing binary incompatible code in userland. Note that handle() in qpa land is very different from handle() in the old qt4 land (where it just implied being binary compatible but platform specific). The handle() that gets the QPlatformWindow etc? Yeah, I guess those serve no great purpose in the public API. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] api changes
On sexta-feira, 13 de abril de 2012 19.18.26, Samuel Rødal wrote: On 04/13/2012 07:08 PM, ext Girish Ramakrishnan wrote: Hi, I am going through all the new apis. I have a couple of more changes to the public apis already. I am not submitting them to api_changes branch. I think Lars and co are having enough trouble as-is with getting api_changes to merge to master :-) All the commits will have the api: prefix in the commit message (so it's easy to see on my dashboard). I will stage them only after api_changes is merged. My current understanding of the qpa plan is this, correct me if I am wrong: 1. Files with _qpa in them are supposed to be used by plugins and plugins only. If you see, _qpa.h being used in application code, they are using a binary and source incompatible Qt. _qpa.h also lacks the 'we mean it' header which I will add. Mostly, though I guess an application might use QPlatformNativeInterface to get access to a platform specific resource (such as the X display or the wayland display or window handles etc). Maybe we'll need to make a public API front-end for that down the line. Let's please not invent a new rule. If it's _p.h, it's private, otherwise it's public and subject to source- and binary-compatibility guarantees. If there's API in some files that we don't want to keep BC on, let's move them to a _p.h file. Plugins can include those since we do install private headers in Qt 5. Also, syncqt will not generate forwarding headers for classes in the _p.h files. This helps us by not including one of them by accident by #include QtGui/QPlatformWhatever. 2. No public Qt include files should have _qpa.h in them Without adding a new rule: No public Qt include files should have _p.h in them 3. _qpa.h files are installed only so that we can allow development of plugins outside of qt source. I would like to see them not getting installed at all but I don't know if this is an oversight or intentional. All headers are installed. This rule is unnecessary. 4. Also, I would like to see all the handle() functions in public api die. Or make them protected and make all the classes friends (as such they are all mostly friends anyway). handle() encourages writing binary incompatible code in userland. Note that handle() in qpa land is very different from handle() in the old qt4 land (where it just implied being binary compatible but platform specific). The handle() that gets the QPlatformWindow etc? Yeah, I guess those serve no great purpose in the public API. Just say that the type of the pointer returned by such functions is not part of Qt's public API. Private Qt API and non-Qt API fall under that definition. -- 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 Summit 2012 Registration is now open!
On 04/12/2012 06:54 PM, ext quim@nokia.com wrote: Alright, forget all this. Let me arrive at home and change the wiki page. I will start by asking people to send me an email with those fields. Any improvement from that lowest point is welcome. Alexandra has been kind enough to provide a patch: a form hosted at http://qt.nokia.com/forms/summit-signup Still a third party from a Qt Project point of view but I guess one that you are more used to trust. Sorry, it was the fastest and simplest way to save us from handling emails manually. PS: But we need to find the right alternative for handling collaborative data online with satisfactory privacy terms. -- Quim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] api changes
Hi Thiago, 2012/4/13 Thiago Macieira thiago.macie...@intel.com: On sexta-feira, 13 de abril de 2012 11.03.58, Girish Ramakrishnan wrote: Hi Thiago, Let's please not invent a new rule. If it's _p.h, it's private, otherwise it's public and subject to source- and binary-compatibility guarantees. If there's API in some files that we don't want to keep BC on, let's move them to a _p.h file. Plugins can include those since we do install private headers in Qt 5. Also, syncqt will not generate forwarding headers for classes in the _p.h files. This helps us by not including one of them by accident by #include QtGui/QPlatformWhatever. All platform plugins, unfortunately, do exactly this. Fixing them all though entirely possible though. There's also some inconsistency with some of the qpa files being named _qpa_p.h :-) How about we fix this properly for 5.1? And for the moment, also have the understanding that _qpa.h is internal? Immediate action then: 1) make sure all such classes are documented \internal, so they don't show up in docs 2) add #pragma qt_no_master_include so that they aren't included in QtGui and people use them by accident because they happened to complete in QtCreator or another IDE 3) no _qpa.h includes in public headers 4) no includes of _qpa.h forwarding headers in public headers either Later: 5) add #pragma qt_sync_stop_processing so that the forwarding headers aren't added, fixing the code that used them 6) rename _qpa.h to _p.h and update all includes to have private/xxx_p.h (there's no need to have qpa in the name, since QPA is the only platform -- it's implied) Yes, agreed (and thanks for those pragmas that I was not aware of). I think the idea with _qpa_ in the file name is to imply that it has plugin api. As opposed to let's say qpen_p.h. This means that when I see a change to a _qpa.h file, I know that plugins will get affected by this api change. However, this fact can already be deduced from the qplatform prefix. The only exceptions, I see are: 1. qwindowsysteminterface, which can be renamed at some point to be qplatformwindowsystemitnterface 2. qgenericplugin, which can also be renamed So, let's rename _qpa.h to qplatform*_p.h. Ok? Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] api changes
Hi, On Fri, Apr 13, 2012 at 11:30 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: I think the idea with _qpa_ in the file name is to imply that it has plugin api. As opposed to let's say qpen_p.h. This means that when I see a change to a _qpa.h file, I know that plugins will get affected by this api change. However, this fact can already be deduced from the qplatform prefix. The only exceptions, I see are: 1. qwindowsysteminterface, which can be renamed at some point to be qplatformwindowsystemitnterface Scratch that. QWindowSystemInterface is meant to be public api, I think. Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] api changes
On sexta-feira, 13 de abril de 2012 11.30.42, Girish Ramakrishnan wrote: Yes, agreed (and thanks for those pragmas that I was not aware of). Remember to wrap them in #if 0, so only syncqt will see them. I think the idea with _qpa_ in the file name is to imply that it has plugin api. As opposed to let's say qpen_p.h. This means that when I see a change to a _qpa.h file, I know that plugins will get affected by this api change. However, this fact can already be deduced from the qplatform prefix. The only exceptions, I see are: 1. qwindowsysteminterface, which can be renamed at some point to be qplatformwindowsystemitnterface 2. qgenericplugin, which can also be renamed qgenericplugin needs to be renamed since it's an oxymoron. The concept of generic plugin makes no sense. Those are QPA extra plugins that can be used independent of the main QPA platform plugin. But they really need to go away completely. It makes no sense for a user to decide to use an extra evdev plugin when running xcb. In fact, I'd also remove the -platform option too. Leave the environment variable for overrides and auto-detection as the main way. So, let's rename _qpa.h to qplatform*_p.h. Ok? Yes, please. -- 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] api changes
On 04/13/2012 08:41 PM, ext Girish Ramakrishnan wrote: Hi, On Fri, Apr 13, 2012 at 11:30 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: I think the idea with _qpa_ in the file name is to imply that it has plugin api. As opposed to let's say qpen_p.h. This means that when I see a change to a _qpa.h file, I know that plugins will get affected by this api change. However, this fact can already be deduced from the qplatform prefix. The only exceptions, I see are: 1. qwindowsysteminterface, which can be renamed at some point to be qplatformwindowsystemitnterface The _qpa in the file name was just the equivalent of _mac, _win, _x11, and _qws in Qt 4.x days. Scratch that. QWindowSystemInterface is meant to be public api, I think. Well, it's used by generic plugins, and maybe also in testlib etc for simulating mouse clicks. It's also different from the QPlatform* classes in that it's not going to be sub-classed in the platform plugins. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] api changes
On 4/13/12 7:18 PM, ext Samuel Rødal samuel.ro...@nokia.com wrote: On 04/13/2012 07:08 PM, ext Girish Ramakrishnan wrote: Hi, I am going through all the new apis. I have a couple of more changes to the public apis already. I am not submitting them to api_changes branch. I think Lars and co are having enough trouble as-is with getting api_changes to merge to master :-) All the commits will have the api: prefix in the commit message (so it's easy to see on my dashboard). I will stage them only after api_changes is merged. My current understanding of the qpa plan is this, correct me if I am wrong: 1. Files with _qpa in them are supposed to be used by plugins and plugins only. If you see, _qpa.h being used in application code, they are using a binary and source incompatible Qt. _qpa.h also lacks the 'we mean it' header which I will add. Mostly, though I guess an application might use QPlatformNativeInterface to get access to a platform specific resource (such as the X display or the wayland display or window handles etc). Maybe we'll need to make a public API front-end for that down the line. I've seen other questions about how to e.g. convert a QPixmap to and from a HBITMAP or get access to other native handles. IMO we should offer APIs for these kind of things in platform dependent add-ons. ie. we have a QtX11/QtMac/QtWinSupport add-ons. That's also a natural place to add feature gaps to Qt 4.x such as QX11Embed into. 2. No public Qt include files should have _qpa.h in them Correct. 3. _qpa.h files are installed only so that we can allow development of plugins outside of qt source. I would like to see them not getting installed at all but I don't know if this is an oversight or intentional. We need to install them, as we want to allow platform plugins outside of qtbase. Ideally, we move them all into a separate directory though, but that would require a bit of build system magic. 4. Also, I would like to see all the handle() functions in public api die. Or make them protected and make all the classes friends (as such they are all mostly friends anyway). handle() encourages writing binary incompatible code in userland. Note that handle() in qpa land is very different from handle() in the old qt4 land (where it just implied being binary compatible but platform specific). The handle() that gets the QPlatformWindow etc? Yeah, I guess those serve no great purpose in the public API. Yes, do we still need it, or should we rename it to something that has the correct name (like platformWindow())? Explicit names would certainly be cleaner, but can break quite some thing currently, so I'd go for adding the new methods and deprecating+inlining the old ones. Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
