Re: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.
On mandag 11. juli 2016 12.54.58 CEST Simon Hausmann wrote: > Instead of using copy(), why not call the non-const bits() function (and > don't use the returned value). That will detach [...] Instead of using bits(), why not call detach() directly? ;) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer
On fredag 13. mai 2016 05.24.03 CEST Shawn Rutledge wrote: > > On 12 May 2016, at 17:05, Jake Petroules wrote: > > > > +1. I touch Windows as little as possible, yet I'm still aware of > > Maurice's prominence in the WinRT space. :) > +1 likewise. +1 from me too :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion for change on how blockers are marked in Jira
On Friday, November 27, 2015 02:23:01 PM Eskil A. Blomfeldt wrote: > I think a batched change for all open reports with a "Fix version" != > "Some future release" would have to be part of this. A quick check > reveals that we (for instance) currently have 27 unresolved bugs with > fix version set to "5.3.0", so this might be a good clean-up to have in > any case. I thought we discussed that this should only apply to P1 (and af course P0) bugs? If a bug is a blocker, it is by definition a P1. There is some sense in allowing non-blocking bugs to have a Fix Version, to aid in planning. As far as I can see, we have 157 bugs that have a Fix Version of 5.3.0 or later. Of those, one is P0, and 25 are P1. About half of those are for 5.3/5.4. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFD: plugins vs QStringLiterals
On Friday 6. November 2015 10.10.52 Thiago Macieira wrote: > But before I go and modify QFactoryLoader... what is that class for? Can > anyone find out from the old history? It traces its existence back to "Long > live Qt 4.5". Added by Matthias in commit 89df363e4a795d67342d04e478af592618e16363 at Thu May 6 13:28:09 2004 "added the new plugin stuff. Not yet used, not yet compiled." Hope that helps. :p But seriously, there does not seem to be a lot more information in the old history than what's in the code today. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Tuesday 20. October 2015 23.37.27 Thiago Macieira wrote: > Em qua 21 out 2015, às 06:29:30, Knoll Lars escreveu: > > As I remember it, the change from QSubString to QStringRef was a simple > > API > > naming decision, i.e. independent of the implementation details. > > Then it must be a coincidence that it changed internals more or less at the > same time. Both were committed at the same time (in change 138d1ab051ed4934b303fa7a43a27dc4004e3ff9 for those who have access to the old Qt history). Date: Mon Jan 15 14:59:53 2007 +0100 Commit message: "Removed QSubString again, and introduced a lower-level class QStringRef" QSubString had a QString::Data *d member, and the initial QStringRef had a const QString *m_string, just like today. I have only skimmed the thread, so I'm probably misunderstanding something, but I don't see how a QString pointer is that much safer than a Data pointer, or a QChar pointer. A safe class would use the implicit sharing by keeping a QString member, but I don't know how that would impact performance. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWaylandCompositor public api
On Wednesday 9. September 2015 18.13.55 Thomas Senyk wrote: > How stable/done is this? Is it worth while trying to port an existing > compositor to the new API? It's in active API review, and we're still tearing down some of the classes. Right now, we are removing absolute positions from the API, since that concept does not really exist in Wayland. We also know that we have to change the input classes. > If it's stable enough to count an effort like that between "API > review" and "actual forward port" then I'd give it a try in 2-3 weeks > (unless something comes up -- as always). In 2-3 weeks, the API should be a lot more stable. That would be the ideal time to give feedback. > What's assumed ETA for moving wip-compositor-api to default API? 5.6? 5.7? We will have a tech preview in the 5.6 timeframe, but we will integrate the changes to the dev branch, and not to the 5.6 branch. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cross-platform high-DPI Qt tech preview
On Sunday 23. August 2015 19.53.51 Knoll Lars wrote: > The changes made it into 5.6. I'm pretty sure documentation will be in place > for the release :) http://doc-snapshots.qt.io/qt5-5.6/highdpi.html#qt-support - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Playground request: qtmirserver
On Monday 10. August 2015 16.34.49 Oswald Buddenhagen wrote: > would the repository be imported as-is (git fast-import from bzr), > filter-branched, or re-created? I think fast-import is the simplest. There are probably some packaging related configuration files that are not relevant in the Qt repository, but they are not large, so they can easily be removed by a normal commit. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Playground request: qtmirserver
On Monday 10. August 2015 16.34.49 Oswald Buddenhagen wrote: > On Mon, Aug 10, 2015 at 02:36:34PM +0200, Paul Olav Tvete wrote: > > So what we are talking about here is the platform plugin for Mir servers, > > together with a Qt Quick plugin for writing a Mir compositor. > > i'm confused ... what is plugged where to do what? I'm probably using the wrong terminology. I think the Qt Quick term is "import". So, part 1 is a platform plugin that is used by the Mir server/compositor process. This is a normal platform plugin, like the xcb plugin or eglfs. The window manager logic is typically written in QML. That QML needs an "import Unity.Application". This import is implemented in src/modules. That directory should probably be renamed as part of the upstreaming process. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Playground request: qtmirserver
On Monday 10. August 2015 14.01.41 Oswald Buddenhagen wrote: > the description on launchpad: > > This projects contains code to integrate Qt with the Mir display > > server as follows: > > - a QPA plugin to enable Qt applications as Mir clients > > - a QPA plugin and support module to enable Qt/QML be a Mir display > > server > > so these are actually two things. That launchpad description seems to be inaccurate: the Mir client plugin is not included in qtmir, but in qtubuntu -- and has already been upstreamed to Qt. So what we are talking about here is the platform plugin for Mir servers, together with a Qt Quick plugin for writing a Mir compositor. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Playground request: qtmirserver
On Monday 10. August 2015 10.59.17 Richard Moore wrote: > On 10 August 2015 at 10:01, Paul Olav Tvete > > wrote: > > I would like to propose a new playground repository for upstreaming the > > QtMir > > > project from Canonical: > Will the canonical developers be working directly in this repository? If > so do we need to consider how their changes will be reviewed (ie. do they > need some approvers). Good question. I can see 30 changes in their repository over the last six months. I think Eskil and I can handle that rate of approvals for now :) As for Canonical approvers, that should follow the standard procedure: Submit good changes and be constructive with your +1s and -1s, and you will get approver rights eventually. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Playground request: qtmirserver
Hi, I would like to propose a new playground repository for upstreaming the QtMir project from Canonical: https://code.launchpad.net/~mir-team/qtmir/trunk I propose the name "qtmirserver", since it is more descriptive than "qtmir". The name "qtmirextras" should be reserved for platform specific functionality needed by client applications running on Mir. - Paul (wearing his QPA maintainer hat) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fwd: (QTBUG-46655) qt5base: font license files missing
On Sunday 14. June 2015 23.18.18 Thiago Macieira wrote: > The file qtbase-opensource-src-5.4.2/lib/fonts/README > states: > 'Copyright statements and the source of the qpf fonts are located in > ../../src/3rdparty/fonts' > > The directory src/3rdparty/fonts does not exist in qtbase-opensource- > src-5.4.2.tar.xz archive. > > This directory exists in the 'old' qt-4.8.7 distribution and contains the > various font license files. > > - > > Does anyone know: > > a) where the font files come from? I don't remember precisely, but most (if not all) were taken from whatever Linux distribution we were using at the time when Qt/Embedded was made (around 1999/2000). > b) what licences apply to them? That should be the licenses contained in the Qt 4 repository. > c) if those font files are still used in any version? There is still code in Qt that reads and adds QPF files if they are installed, but I do not believe this is commonly used. In any case, if someone needs QPF fonts they can get them from other sources than the Qt packages. It sounds like a good idea to remove the font files from qtbase. TL;DR: Nuke it from orbit. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Are SiCs through #include cleanups considered acceptable?
On Tuesday 14. April 2015 08.33.06 Mathias Hasselmann wrote: > So we finally have reached the turning point at which we have no chance > but to make C++11 mandatory for public Qt headers: You might think you're trolling, but I think requiring C++11 would be an excellent goal for Qt 6. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QGView and deprecated indirect painting
On Wednesday 1. April 2015 13.28.50 Christian Gagneraud wrote: > So, my question is: Do you guys plan to remove this feature, and if yes > (which seems likely to me), how could I then control colors, opacity and > drawing order on a per view basis? There is very little new development for graphics view. Essentially, we focus on stability, and only serious bugs are fixed. I will be very surprised if anyone would think it is a good idea to do a large change to remove features at this point, even if they are deprecated. However, there is a theoretical possibility that changes in other parts of Qt could break this feature, and in that case we might not prioritize fixing those bugs. TL;DR: No plans to remove it, but no guarantees that it will always continue working. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Timur Pocheptsov as approver
On Thursday 22. January 2015 06.52.56 Blasche Alexander wrote: > > I'd like to nominate Timur Pocheptsov for approver status. +1 from me too :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform maintainers
On Friday 5. December 2014 10.56.48 Thiago Macieira wrote: > Was there anyone who did not get seconded? No. You approved all of them. :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [FYI] new git-gpush features, a.k.a. the smart way of pushing to gerrit
On Thursday 23. October 2014 19.03.32 Oswald Buddenhagen wrote: > just to be clear, everybody is expected to use these scripts after they > leave the beta phase. > this will be technically enforced at some point. Sorry Ossi, your calendar is broken. It's not April the first today. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some more maintainer nominations
On Monday 13. October 2014 11.36.43 Knoll Lars wrote: > Qt WebView: Christian Strømme +1 Christian: you need to work on self promotion, obviously :p - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers
On Tuesday 16. September 2014 07.31.01 Reinio Topi wrote: > I'd like to nominate Venugopal Shivashankar and Nico Vertriest as approvers > in the Qt Project. +2 - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Jira component re-arrangements
On Tuesday 03 June 2014 07:05:07 Blasche Alexander wrote: > Hi Gatis, > > Thank you very much for stepping up. I have not seen any further volunteers > and I think it is safe to assume that there won't be anybody else at the > moment. I have set you up as the default assignee. +2 I think I would have volunteered Gatis if he hadn't done it himself :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating JIRA components relating to events.
On Monday 28 April 2014 08:42:48 Blasche Alexander wrote: > I renamed it on request. It was such a minor change that I didn't see an > issue especially since the component doesn't have a default assignee. > Obviously that is not the case. No worries :) I may be using the components in a slightly non-standard fashion, but I do like to add additional components to tasks, instead of using one component and several labels. In this case, I used the combination of "QtPorts: Android" and input methods to track the input method issues on Android. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating JIRA components relating to events.
On Friday 25 April 2014 17:27:23 Thiago Macieira wrote: > I've just noticed that the "GUI: Input methods" component in JIRA has got > an update now saying "(Non-Latin languages)". That is, it seems the > purpose of that component has changed to mean complex input methods only. > > I've been reassigning to that component anything that is related to *any* > input method, especially mouse, keyboard and touch, which bug reporters > often submit to "Core: Event System". > > Can I ask that we create a "GUI: Basic Input Method (keyboard, mouse, > touch)" component? Does anyone feel like being the default assignee? > Please reply in QTJIRA-258. As I commented in the task, I would like to request a reversal of the "Non- Latin languages" renaming. On Android, we use exactly the same infrastructure for input of Latin-based languages. (Also, there are several non-Latin scripts that can use simple keyboard input on a desktop computer.) If we have to rename, I support Thiago's suggestion of "Complex input methods", possibly with a "text" or "language" thrown in. [Apology in advance for small rant.] In the future, could we please not rename components silently without warning? This renaming effectively edited several of my tasks, making them misleading. As a bonus it also messed up my filters. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] One 'qt' branch to rule 'em all!
On Tuesday 01 April 2014 11:12:18 Koehne Kai wrote: > So, here is what we will do: > - create one branch named 'qt' out of current stable > - block any other branches in gerrit > - move on with this branch, and announce the current status of it (open for > features, feature freeze, hardening...) on the mailing list [...] > If there are no fundamental objections I'd like to see this into action as > early as possible, to not risk the 5.3.0 release (i.e. next week Thursday, > when we originally planned to merge to release branch). This is indeed great news! We have used this model previously in the Trolltech days, and our productivity back then was a lot higher: we only needed four developers to release Qt 1.0. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android: SEGV in Qt 5.3 (not in Qt 5.2.1)
On Thursday 20 March 2014 19:00:54 Cornelius Hald wrote: > maybe someone > already could make some assumptions based on the console output below. [...] > W/Qt (15487): kernel/qmetaobject.cpp:1458 (static bool > QMetaObject::invokeMethod(QObject*, const char*, Qt::ConnectionType, > QGenericReturnArgument, QGenericArgument, QGenericArgument, > QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, > QGenericArgument, QGenericArgument, QGenericArgument, > QGenericArgument)): QMetaObject::invokeMethod: No such method > ScalableTextInput_QMLTYPE_3::inputMethodQuery(Qt::InputMethodQuery,QVariant) This warning is expected, and does not indicate that anything is wrong. (It basically says that I should hurry up and finish https://codereview.qtproject.org/#change,81053 before the RC) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android / IOS
On Tuesday 18 March 2014 12:50:26 m...@rpzdesign.com wrote: > Hello Development: > > I am newly arrived on Qt 5.2x scene and wanted to know how to contribute > code, fixes, > and testing for Qt 5.3.x of IOS and Android. > > Specifically, I want to focus on QT C++ <-> Objective C/Cocoa bridge > and QT C++ <-> Android/Java/JNI. > > Is the development email list a free flowing forum or are there > different subgroups > each with their own list or developer forum somewhere. > > Where can I access threads of those focused on Android and IOS > integration issues? > > Thanks for any replies, Hi Marco, and welcome to Qt mobile development! :) Code, fixes and testing are all very welcome. There is no shortage of things to do on iOS and Android. development@qt-project.org is free-flowing and covers all aspects of Qt development. In addition there is a mailing list focused specifically on Qt for Android: android-developm...@qt-project.org. This list is much lower volume, and the Qt for Android developers will probably follow that more closely. Issues that are common to several platforms should be discussed here, though. Most of the day-to-day discussion happens on IRC: Android developers hang out on #necessitas on freenode, but mainly during European working hours. I'm not really sure where the iOS developers hang out, but you can find some of them on #qt-labs, #qt-platforms or #qt-lighthouse :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick 2 offscreen rendering
On Tuesday 18 March 2014 10:12:35 André Bergner wrote: > So what is the "official" way to render a QQuickView scene to an offscreen > target while keeping it "alive"? > > I remember talking to somebody at the last Qt dev days in Berlin. He was > suggesting some solution that should make this possible with Qt 5.2. Not officially supported, and not 5.2, but QQuickRenderControl, which is private API in 5.3, does support this usecase. We do plan to make this class public in a later Qt release, soI would recommend it if Qt 5.3 is an option. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Q_WS_* used in Qt sources
On Wednesday 12 March 2014 10:57:19 Thiago Macieira wrote: > Em qua 12 mar 2014, às 18:46:15, Martin Koller escreveu: > > For me the code porting looks a bit "unfinished" due to this Q_WS > > artefacts, so I just fear that problems arise. > > It's possible. Yes, there are still probably some regressions from 4.x left after the QPA rewrite of the Qt internals. However, the fact that we have not cleaned up all the #ifdefs yet is not an indication of that. In Qt4 times, QPA was one of several platforms. At that time we kept the old Q_WS_* code alive while creating the QPA plugins. We could not remove the old #ifdefs then, even after implementing the corresponding functionality in QPA. The fact that we have not removed all the old dead code afterwards is mainly an indication of how much time we have to fix P2 and P3 tasks: it mainly happens when someone is working on the relevant part of the code anyway. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QPA / QWindow / QPainter
On Monday 10 March 2014 09:20:14 Agocs Laszlo wrote: > > > Question: when a QWidget now creates a QPainter on it, how does my QPA > > > plugin know onto which QWindow it is currently acting, when there's only > > > one paintDevice/one backing store ? > As for the painting step, QPA has almost nothing to do with it: you merely > provide a QPaintDevice, the rest is up to the widgets. The QPA plugin has > no knowledge or interest in what's happening in there. The interesting part > is the flush that happens afterwards, and in flush() you will of course > know which QWindow is being flushed. This functionality comes from early Qt 4 days, before non-native widgets were implemented. All widgets paint to the same backingstore, and then each widget gets its content from the part of the backingstore it covers. This way we got the illusion of partially transparent widgets even if the underlying windowsystem did not support it. After non-native widgets (AKA "alien") were implemented, this feature is much less important, and we would probably not implement it like that today. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/Android Ministro Question
On Wednesday 25 December 2013 01:53:14 BogDan wrote: > Well, from your mail it looks like Ministro is a second class citizen > deploying method which IMHO is not true at all. Bundling Qt libs into the > apk is *one* of the official *ways*, meaning that Ministro is also *one* of > the official *ways* ;-)! Every deploying method has advantages and > disadvantages but it doesn't mean that one is more official than the other. I think Tuukka was wearing his Digia hat when writing that mail :) The Qt Project does indeed supports two different deployment method (and a third one for debugging purposes). Ministro was developed by and is maintained by BogDan. The bundling option was done by Eskil for Digia, so we feel more responsible for that one. (Another factor is the support that Digia offers to its customers...) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QPA maintainer
On Tuesday 17 December 2013 08:52:59 Thiago Macieira wrote: > On terça-feira, 17 de dezembro de 2013 11:42:56, Knoll Lars wrote: > > Hi, > > > > I’d like to nominate Paul Tvete as the formal maintainer of the QPA > > architecture. He’s the original architect behind it anyway, and I don’t > > think there are many people out there who know it better :) > > +1 from me, there's no one better than him, unless we can convince Tom > Cooksey to come back :-) I asked, but unfortunately he doesn't have the time. :) Thanks for the votes of confidence so far! - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt5.2 snapshot available
On Tuesday 12 November 2013 13:03:30 Guido Seifert wrote: > > Which version of Qt is this? It works for me with QT += svg only, with the > > latest dev branch. > > qt-linux-opensource-5.2.0-beta1-android-x86-offline_2013-11-07_15-41-07-136. > run > > Maybe it is fixed. But not to the time when I asked. :-) Yes, It was fixed the day after ;) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt5.2 snapshot available
On Monday 11 November 2013 17:19:43 Guido Seifert wrote: > > It's a feature. :) To reduce the size of the package, we only deploy the > > libraries that we know are necessary. Adding "QT += svg" to the .pro file > > of your application should enable support for svg files. > > It does not. But it is a known bug. Already reported. "QT += svg" is NOT > sufficient. Currently it must be "QT += svg xml". Which version of Qt is this? It works for me with QT += svg only, with the latest dev branch. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt5.2 snapshot available
On Friday 08 November 2013 01:00:11 Guido Seifert wrote: > I cannot display svg files in QML on Android. > > Unfortunately I am not experienced enough with Android/Qt to decide, whether > this is my bug, or a Qt bug. It's a feature. :) To reduce the size of the package, we only deploy the libraries that we know are necessary. Adding "QT += svg" to the .pro file of your application should enable support for svg files. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Announce] Qt 5.2 Beta released
On Friday 25 October 2013 11:09:55 qtmail wrote: > Qt 5.2 Beta, Could I customize thesize of apk? > > When create a QT Quick2 "hello world" on android,the apk size up to > 10.6M, so > Could I customize the libs? or all libs is /required/for QT Quick2? As BogDan said, we are aiming to fix it before the release. (See https://bugreports.qt-project.org/browse/QTBUG-34098) It is also possible to customise the package by listing all the libraries and plugins under ANDROID_DEPLOYMENT_DEPENDENCIES in the .pro file. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Novice question for first-time contributions
On Thursday 26 September 2013 17:12:09 Mandeep Sandhu wrote: > I had pushed my changes to the ref- "refs/for/stable" (as shown in the > Gerrit wiki page). Is that correct or do I need to send it to the 'dev' > branch? Stable is correct for bug fixes that target the upcoming release. > Also, whats the correct way to solicit a review? Should I check with > reviewer about his/her availability before adding them on Gerrit? Just add people on gerrit. If you get it wrong it's no big deal, and it is easy to remove oneself from a change. ...and last but not least: Hi, and welcome to the Qt project :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending Jira changes
On Friday 23 August 2013 08:36:07 Blasche Alexander wrote: > I looked into the desired workflow changes for Jira (as discussed on this > list) and am doing some general cleanups [...] Thank you, thank you. Thank you. Thank you! :) - Paul PS, Thank you very very very much! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] PSA: Qt Project IRC logs & statistics
On Thursday 02 May 2013 16:30:47 Alan Alpert wrote: > But if you're addressing this > from a practical standpoint, just ask Robin to skip join/part events > in what his bot publishes instead of losing the valuable dialogue as > well. +2 for not publishing join/part events, including the "*** ChanServ gives paulot permission to talk." Aggregated, they can reveal way to much personal information. Also, they only add noise. (Doesn't everybody hide join/part messages in their IRC clients anyway?) I think having a public log of the discussion can be very useful, but I would not insist on it: +1 but those who feel strongly about it can decide. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt modules missing mandatory LICENSE files
On Friday 15 February 2013 11:43:10 Stephen Kelly wrote: > On Friday, February 15, 2013 12:28:32 Timo Jyrinki wrote: > > At least qtpim, qtsystems, qtconnectivity, qtfeedback > > and qtwayland will follow later, and I'll be filing change proposals > > for them at that time as part of the process. > > I don't know why you're packaging those. > > You understand that they are not 'part of Qt 5', right? > > And you understand that they are not stable in any way and their API will > likely change, and they will not be part of Qt 5.1, and they may never be > part of a Qt release? AFAIK, QtWayland is planned to be part of Qt 5.1. (Parts of the module will be marked as experimental.) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Andreas Hanssen as Approver
On Thursday 7 February 2013 09:44:38 Eskil Abrahamsen Blomfeldt wrote: > On 02/06/2013 10:31 PM, Thiago Macieira wrote: > > Hello > > > > Andreas is a long-time Qt developer. For those of you who haven't yet had > > the pleasure of meeting him, he's the brains behind the original > > implementation and maintenance of Graphics View. Before that, I remember > > working with him on the networking classes -- in fact, QSslSocket is also > > his and George Staikos's. > > +1 of course > > Also a bit surprised to hear that he's not already an approver. :) This is getting a bit repetitive, but me too :) everything that's said above plus one. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Wednesday 6 February 2013 09:41:46 Paul Olav Tvete wrote: > On Wednesday 6 February 2013 09:00:41 Thomas McGuire wrote: > > A workaround would be to squash all commits of the branch together into a > > single patch and then upload that to Gerrit for review. Now, actually > > pushing the single patch would lose history, so we'd instead manually do > > a > > proper merge of the branch. How about we do that for the Android merge? > > That's a great idea! We can push a squashed commit as a WIP to gerrit. I > think we should do a preliminary one this week. (And yes, this is a "we > should" that means "I will" in the old Trolltech tradition :) Here is a squashed commit of all changes to qtbase, for those who like to see everything in one place: https://codereview.qt-project.org/#change,46976 qtdeclarative: https://codereview.qt-project.org/#change,46983 qtsensors: https://codereview.qt-project.org/#change,46984 - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Wednesday 6 February 2013 09:00:41 Thomas McGuire wrote: > A workaround would be to squash all commits of the branch together into a > single patch and then upload that to Gerrit for review. Now, actually > pushing the single patch would lose history, so we'd instead manually do a > proper merge of the branch. How about we do that for the Android merge? That's a great idea! We can push a squashed commit as a WIP to gerrit. I think we should do a preliminary one this week. (And yes, this is a "we should" that means "I will" in the old Trolltech tradition :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Reviews needed before android integration in two weeks
One of the major features for Qt 5.1 is Android support. We have been doing the work in a feature branch, and are now getting ready to integrate to the dev branch. To beat the rush of integrations before feature freeze, we aim to start the integration in two weeks time. Most of the changes are android-specific, but there are a few changes touching cross-platform code. To make the integration go smootly, we ask approvers and maintainers to check the android changes in their areas now, so we can fix any problems before the merge. To see the changes, check out (or diff against) the "wip/android" branch. I have appended a list of changed files for the following repositories: qtsensors qtdeclarative qtbase We also have changes in qtmultimedia, but those will probably be merged independently. We urge you to check your area for changes within the coming two weeks. Once the merge commit is created, we aim to integrate it immediately, so there will not be room for a lot of discussion at that point. On behalf of the Qt for Android team, - Paulqtdeclarative M src/quick/items/qquickitem.cpp M src/quick/items/qquicktextedit.cpp M src/quick/items/qquicktextedit_p_p.h M src/quick/items/qquicktextinput.cpp qtsensors A src/plugins/sensors/android/... M src/plugins/sensors/blackberry/main.cpp M src/plugins/sensors/dummy/main.cpp M src/plugins/sensors/generic/main.cpp M src/plugins/sensors/linux/main.cpp M src/plugins/sensors/sensors.pro M src/plugins/sensors/simulator/main.cpp M src/sensors/qsensormanager.cpp M src/sensors/qsensorplugin.h qtbase M config.tests/qpa/linuxfb/linuxfb.cpp M config.tests/unix/arch.test M config.tests/unix/compile.test M config.tests/unix/evdev/evdev.cpp M config.tests/unix/getaddrinfo/getaddrinfotest.cpp A config.tests/unix/ipc_android/ipc.cpp A config.tests/unix/ipc_android/ipc_android.pro M config.tests/unix/makeabs M configure A lib/rules.xml A mkspecs/android-g++/qmake.conf A mkspecs/android-g++/qplatformdefs.h D mkspecs/common/android/qplatformdefs.h D mkspecs/common/linux-android.conf A mkspecs/features/android.prf A mkspecs/features/java.prf M mkspecs/features/moc.prf A mkspecs/features/qpa/android.prf M mkspecs/features/qpa/genericunixfontdatabase.prf M mkspecs/features/qt_functions.prf M mkspecs/features/qt_parts.prf M mkspecs/features/resources.prf M mkspecs/features/static.prf D mkspecs/unsupported/linux-android-armeabi-g++/qmake.conf D mkspecs/unsupported/linux-android-armeabi-g++/qplatformdefs.h D mkspecs/unsupported/linux-android-armeabi-v7a-g++/qmake.conf D mkspecs/unsupported/linux-android-armeabi-v7a-g++/qplatformdefs.h D mkspecs/unsupported/linux-android-x86-g++/qmake.conf D mkspecs/unsupported/linux-android-x86-g++/qplatformdefs.h M qmake/generators/makefile.cpp M qmake/generators/unix/unixmake2.cpp M qmake/generators/win32/mingw_make.cpp M qmake/generators/win32/msvc_nmake.cpp M qtbase.pro A src/android/... M src/corelib/arch/arch.pri A src/corelib/arch/qatomic_android.h M src/corelib/codecs/qiconvcodec.cpp M src/corelib/codecs/qiconvcodec_p.h M src/corelib/codecs/qtextcodec.cpp M src/corelib/codecs/qtextcodec_p.h M src/corelib/global/qglobal.cpp M src/corelib/global/qlogging.cpp M src/corelib/global/qnamespace.h M src/corelib/global/qnamespace.qdoc M src/corelib/global/qsystemdetection.h M src/corelib/io/qabstractfileengine_p.h M src/corelib/io/qfilesystemengine_unix.cpp M src/corelib/io/qfsfileengine_unix.cpp M src/corelib/io/qtemporarydir.cpp M src/corelib/kernel/kernel.pri M src/corelib/kernel/qeventdispatcher_unix.cpp M src/corelib/kernel/qeventdispatcher_unix_p.h M src/corelib/kernel/qsharedmemory.cpp D src/corelib/kernel/qsharedmemory_android.cpp A src/corelib/kernel/qsharedmemory_ashmem.cpp M src/corelib/kernel/qsharedmemory_p.h M src/corelib/kernel/qsystemsemaphore.cpp M src/corelib/kernel/qsystemsemaphore_android.cpp M src/corelib/kernel/qsystemsemaphore_p.h M src/corelib/thread/qbasicatomic.h M src/corelib/thread/qthread_unix.cpp A src/corelib/tools/android/cpu-features.c A src/corelib/tools/android/cpu-features.h M src/corelib/tools/qsimd.cpp M src/corelib/tools/qstring.h M src/corelib/tools/tools.pri M src/gui/image/qimage_neon.cpp M src/gui/kernel/qguiapplication.cpp M src/gui/kernel/qplatforminputcontext.cpp M src/gui/kernel/qplatforminputcontext.h M src/gui/kernel/qplatformmenu.h M src/gui/kernel/qplatformscreen.cpp M src/network/access/qnetworkaccessfilebackend.cpp M src/network/access/qnetworkaccessmanager.cpp M
Re: [Development] abandoning stale changes on gerrit
On Thursday 31 January 2013 13:08:11 Oswald Buddenhagen wrote: > as i stated before, i'm driving forward a process to decide the > execution details of a previously made decision. Since this decision process has been unnoticed by the people I have asked: Would you mind giving a reference to where this was discussed? - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] issue in minimal plugin
On Wednesday 30 January 2013 07:58:25 Thiago Macieira wrote: > On quarta-feira, 30 de janeiro de 2013 17.17.46, Mumtaz Ahmad wrote: > > Hi, > > > > I am trying to run rasterwindow example using minimal plugin but i am > > getting null paint device > > QPainter::begin: Paint device returned engine == 0, type: 3 > > > > Is it known issue in QT5.0? > > The minimal plugin is not meant to be used when running applications. It's > meant only as a helper for porting Qt to new platforms and writing new > plugins. The minimal plugin is definitely not suited for production. No-one needs to fill up their file system with screenshots of a running application. However, there are cases where something like the minimal plugin is useful for real applications: WebKit is one example. I recently had a discussion with Simon about this, and the solution we came up with was moving the current minimal plugin to examples, and write a new plugin for applications that need to do graphics without connecting to a windowing system. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Importing Snowshoe QML browser to the Qt project
On Thursday 24 January 2013 21:18:30 Hausmann Simon wrote: > There haven't fortunately been any objections yet to this proposal, also > unfortunately also no approval yet from a Qt maintainer. Anyone willing to > approve the inclusion? How about I propose it and you approve? :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 for Android developer mailing list
On Tuesday 8 January 2013 15:49:32 Laszlo Papp wrote: > I personally expected that you need this list for something permanent that > is out of the scope for the existing mailing lists, like development@, qt- > components@, and so forth. I still did not get any examples what development > cannot happen in public with other platform developers... I'll try once more: We have identified the need for a dedicated channel of communication for a new project with a rather tight deadline. We would like that channel to be publicly visible so that that others can follow what we do. The primary purpose is to facilitate the project. Keeping others informed and getting input from people not participating is a secondary objective. We need somewhere to talk anyway. The question we are asking here is whether you want us to talk in private, or whether we should talk on a mailing list on qt- project where everyone can listen in. The Qt 5 for Android project would be fine either way, but personally I think it would be a loss for the community if we used a private channel. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 for Android developer mailing list
On Tuesday 8 January 2013 15:13:38 Laszlo Papp wrote: > We do not have separate lists for Mac, QNX, Windows, Linux, Harmattan, > Symbian and so forth so far, so I am wondering: what exactly would not fit > the existing mailing lists? This is a new project, and we need a convenient way to communicate inside that project. Using the development mailing list is not an option for us: there's way too much activity here. The options are 1) discuss openly in a dedicated list where everybody who's interested can see what's happening, or 2) just send the mails directly to the active developers. We really want to be open and transparent about what happens, but not everybody has the time to check this list several times a day, so we would be forced to communicate somewhere else if we don't get a dedicated list. Edit: and as Maurice says, we can shut down the list when it's no longer useful. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Documentation, the final kilometre
Hi all, Now that we have merged the newdocs branches to master, it is time to polish up the documentation for the final release. Lars already put this better than I could: On Monday 19 November 2012 20:09:35 Knoll Lars wrote: > However, there is still significant work still to write many overview > documents. The team in Oslo will in the next days do an extra effort to > create these overviews. When reviewing the first set of patches, please do > mainly review the content, not the form or language. We'll do a second > iteration over the docs once they are in to fixup any potential > style/language issues. > > We'll post some more info on this tomorrow, and I'd like to invite everybody > to have a look at http://community.kde.org/Qt5/Documentation if you want to > help. There is not a lot of time left, so we will concentrate what is most important for a good first impression: 1. The new overview documentation that was written as part of the newdocs project still has a lot of skeleton pages and "### TODO" comments. They need to be fleshed out with complete sentences. Many people here in Oslo have already been volunteered for this, and we will continue to walk around and ...encourage people to sign up for these pages. 2. We have identified around 130 existing documentation pages that need attention. Most of these have minor issues that can be fixed in a couple of minutes, so if everyone in the Oslo team takes care of a couple of pages, we will have this sorted in no time. Of course we welcome contributions from all members of the community, not only the ones with the really horrible weather :) The procedure is the same for all. Instead of having one JIRA task for each page, there is a wiki where you can sign up: http://community.kde.org/Qt5/Documentation/OverviewClassification (Big thanks to KDE for letting us use their wiki after we discovered that the qt-project wiki does not handle editing conflicts well.) The new documentation is available on doc-snapshot (currently without the right styling, since we're waiting for some changes to integrate) on http://doc-snapshot.qt-project.org/5.0/qtdoc/ Known bug: Most images are missing. Building the documentation yourself is very easy now: If you have a working qt5.git checkout, all you need is 'make docs' in the toplevel directory. Now, let's go get some documentation fixed! - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cleanup of QCoreApplication::watchUnixSignal
On Thursday 25 October 2012 12:16:40 Rafael Roquetto wrote: > Afaik QCoreApplication::watchUnixSignal() seems to be no longer used, at > least in Qt5. If that is really the case, would anyone object doing away > with it (and removing the overhead from QEventDispatchUnix::doSelect() and > co.)? Otherwise, what are the possible use cases? > > Any thoughts? As the original author, I agree that it should be removed. Since watchUnixSignal() is not implemented for the GLib event dispatcher, developers cannot rely on it being available. Also, the original use case is no longer relevant: it was used by QWS to detect virtual console switching. The recommended way to watch for UNIX signals in Qt is: http://doc-snapshot.qt-project.org/5.0/unix-signals.html (making a signal handler that writes to a socket). - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Stepping down as the maintainer of QtWayland
On Wednesday 24 October 2012 11:51:09 Jørgen Lind wrote: > I'm stepping down as the maintainer of QtWayland, as I don't have time > to ensure that QtWayland is in top notch shape. I'm sad to hear that, but it's not completely unexpected. Thank you very much for all the brilliant work and enthusiasm you have put in to make QtWayland what it is today. > I would like to propose Andy Nichols as the new maintainer. +1 from me; Andy has been the de facto maintainer for a while already. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Profile support on Qt
On Thursday 02 August 2012 10:31:59 ext Olivier Goffart wrote: > If that's only a documentation problem, we can workaround that with some > macro magic. Very good point. For some reason I thought we would have to hack on qdoc itself, but creative use of \fn and \internal should be enough. > Should that even go in the constructor? Maybe QImage::setColorProfile. The problem with that is that it is not clear from the name whether it converts the image data to the new profile, or just overrides the profile. Also, overriding the profile is really just needed for specifying the profile when constructing the image. > On the other side, if we add it now, and realize this should not be pointer, > or should not be even in QImage. Then it is too late to change. Those are good points. Of course we could still add new constructors, and use qdoc magic to hide the pointer argument in that case :) The only other point I can see is saving 6 extra exported symbols in Qt 5.1, and I realize that that's not a very strong argument. TL;DR: I will not disagree if the consensus is to revert the change. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Profile support on Qt
On Thursday 02 August 2012 07:53:25 ext gunnar.sle...@nokia.com wrote: > On Aug 1, 2012, at 6:37 PM, ext Stephen Kelly wrote: > > Hi there, > > > > Given that https://codereview.qt-project.org/#change,31387 has been > > merged, can you post any more information that will last until the > > QColorProfile class can be implemented? Any ideas on API or > > implementation? > > Alexandros, I would prefer that you reverted that change. It makes little > sense to introduce it without the actual color profiles, and the > constructor can be added in 5.1 as an overload in a binary compatible > manner, so no need in rushing it. I was part of that API discussion when you were away, Gunnar, so I'll chime in with my argument for doing it this way: If we do it in 5.1, we have to add 6 new constructors to QImage, in addition to the 10 existing ones. That will not make the documentation any more readable. I'll let Alexandros answer the rest of the questions, but will just note that he has a complete and fairly polished implementation that he is ready to publish. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QWindowSystemInterface out of QPA
On Tuesday 24 July 2012 17:15:37 Girish Ramakrishnan wrote: > On Mon, Jul 23, 2012 at 4:31 AM, wrote: > > How about a third solution, that only exposes the three methods that are > > being used by QTestLib? We could turn QWSI into a namespace, and forward > > declare the required methods in qtestkeyboard.h etc. > > Why didn't I think of that :) Maybe because QTestLib also uses the TouchPoint struct definition? > This is of course a much simpler > solution. I guess we don't even need QWSI to be a namespace for this, > do we? I just need to forward declare the three methods. > > Let me give it a shot. I have now made an attempt: https://codereview.qt-project.org/31613 it was slightly more complex than I thought it would be :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Qt Embedded
On Friday 22 June 2012 11:09:25 ext Donald Carr wrote: > The Raspberry Pi is also meant to have a discrete (and apparently > meaty) OpenVG processor that is currently lying dormant. This turns out not to be the case after all. In the OpenVG session, we were informed that the Raspberry Pi does actually use the same silicon for OpenGL ES and OpenVG. There is no magical gain in performance from running GLES and VG in parallel :/ (Apparently there was some confusion with dispman, which is completely separate.) There are other chips that have separate VG silicon, or even no GLES at all, so there is still a strong usecase for OpenVG. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Thursday 19 April 2012 14:45:29 ext Girish Ramakrishnan wrote: > Paul did say on irc this proposal sounds 'better', but I am not sure > that means I have his +2. Is this any better? (read: compromise) At least it means that I am withdrawing my -1 :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Wednesday 18 April 2012 16:18:09 ext casper.vandonde...@nokia.com wrote: > Just for my mental state of mind: will these classes then be documented as > normal classes, or \internal, or do we need something special for them > still? They should not be documented as normal classes. \internal is fine for 5.0 if we don't have time to make something special for them. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote: > As per the previous discuss, I renamed all the _qpa.h to _p.h with a > couple of helper scripts I just added the following "-1" comment on gerrit: I do not agree with this change. We have made a difference between public API and plugin API, and this is different from private implementation detail. The rest of the Lighthouse team are also skeptical. The main issue, as far as I can see, is documentation. This can be solved much in a much simpler way by using the \internal tag, as discussed earlier. There should also be a warning in the _qpa.h files, but it shouldn't be the "don't even think of using this file" warning from the _p.h file; these files are there for platform plugin authors to use. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
