Re: [Development] [Qt 4.8 with directfb]Web image rendering problem
2012/8/2 Fred Fung duoduo1...@gmail.com Hi all, I'm trying to view http://www.youtube.com/leanback using QTWebKit in Qt4.8.1(configure with -plugin-gfx-directfb option). There are some images in the web page seems that Qt4.8 isn't able to render them correctly. If I use Qt4.7.4 with directfb, all images are rendered correctly. If I use Qt4.8.1 with X11 system, everything is ok too. Dose someone encounter the same problem? For more information, please visit https://bugreports.qt-project.org/browse/QTBUG-26729 thanks. best regards，fred fung Does somebody know how to fix this issue? thanks. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods
On Friday 03 August 2012 15:42:49 marius.storm-ol...@nokia.com wrote: On 03/08/2012 07:49, ext Thiago Macieira wrote: And operator== can't change incompatibly. Does this mean that we should have an bool QDateTime::isIdentical(const QDateTime dt) function too (effectively an operator===), allowing you to easily check if two dates refer to the same time in the same TZ? It might be a good idea. But don't rush it - there is time for this in Qt5.1. Konrad 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] Cleanups for qt5.git
On 06/08/2012 03:47, ext lars.kn...@nokia.com wrote: ... The first one is the fact that we have a few modules in there that are basically unmaintained for a year and not really functional anywhere. The document gallery is such an example and is the first one I would like to remove (see https://codereview.qt-project.org/#change,32215). +2 ... The other problem is a more general issue that is has become difficult to get qt5.git moved forward and updated to newer tags. I wonder whether it wouldn't be easier to have a list of modules that contains less add-ons (ie. focuses more on the essentials plus some selected additions), but then maybe adds in qt-creator. IMO this could in the longer term be more useful for SDK creation and releasing. Add-on modules that are not part of this new qt5.git, could then always get tested against the latest qt5.git instead of the latest master branches of all modules. IMO qt5.git should only contain the Qt Essentials. If you have selected additions there should really be a discussions on why these are selected additions and not essentials. For the purpose of SDK creation, we can always have another level of super project which includes qt5.git, and any selected additions you would want in the SDK. At some point I think we would want most addons built in binary form when they are ready, as per maintainers opinion. Then the online installers can give people the choice to select any addon they wish to install, and an indication of which version of the addon they will be installing. This of course means that there will be too many permutations to actually test, but I think that's fine for general addons. What's important to test before each release is the strict set of Qt Essentials + Qt selected modules (and keeping the latter set really restricted in size). I do agree that the add-on modules should be tested against the last successful tested version of Qt Essential. That way we can cache this binary version until a new successful one replaces it, and we save valuable time and resources. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Essentials
On 08/06/2012 12:52 PM, lars.kn...@nokia.com wrote: We already have QT_BEGIN/END_NAMESPACE macros used throughout, as well as a module specific qmoduleglobale.h. So I would think it should be possible to do the change in a rather straightforward way. I can't see how this could destabilise the code. All of this change is fully checked at compile time. It might be a problem when exposing types to QML as properties: https://bugreports.qt-project.org/browse/QTBUG-15459 As far as I can see from the commit mentioned in the bug, the fix for Qt5 is just to document the current behaviour, and doesn't actually remove the need to specify the namespace. Also, if the namespace is not specify, QML doesn't report *any* error message at all; it just doesn't work properly (at least in Qt4). But I didn't check if this issue affects any of the classes defined in the modules in question. Anyway, I generally support the idea of using namespaces. :-) Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Content freeze for Qt 4.8.3 approaching
On Friday, August 03, 2012 13:10:43 Salovaara Akseli wrote: There are a few contributions pending to be merged to 4.8 in Gerrit (link: http://codereview.qt-project.org/#q,project:qt/qt+status:open,n,z). It would be great if all maintainers who have not yet done so go through these for their modules and all contributors who have received comments try to fix the things needed to be accepted. Please also note that your contributions to Qt 4 should be in Qt 5 first, otherwise they get lost as there is no way to track patches which were not forward-ported, and no reason *not* to get them into Qt 5 first. http://thread.gmane.org/gmane.comp.lib.qt.devel/4390 Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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 4.8 with directfb]Web image rendering problem
Message: 2 Date: Mon, 6 Aug 2012 14:57:38 +0800 From: Fred Fung duoduo1...@gmail.com Subject: Re: [Development] [Qt 4.8 with directfb]Web image rendering problem To: development@qt-project.org Message-ID: calv-t3351o6fp6mzbqvp44qhxwr6lqqowvh+j2c5t5aqpnu...@mail.gmail.com Content-Type: text/plain; charset=gb2312 2012/8/2 Fred Fung duoduo1...@gmail.com Hi all, I'm trying to view http://www.youtube.com/leanback using QTWebKit in Qt4.8.1(configure with -plugin-gfx-directfb option). There are some images in the web page seems that Qt4.8 isn't able to render them correctly. If I use Qt4.7.4 with directfb, all images are rendered correctly. If I use Qt4.8.1 with X11 system, everything is ok too. Dose someone encounter the same problem? For more information, please visit https://bugreports.qt-project.org/browse/QTBUG-26729 thanks. best regards?fred fung Does somebody know how to fix this issue? thanks. https://codereview.qt-project.org/#change,30858 can you try the patch above? regards Haithem. -- * Never say that's impossible, the word itself says I'm Possible * ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QT_FOR_PRIVATE and QT_PRIVATE in .pro files?
What do these two variables mean? I saw QT_PRIVATE before and now I see QT_FOR_PRIVATE in .pro files from qtjsondb (client.pro, for example). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting up time-based releases for the project
Thiago Macieira wrote: Thanks for putting it together. I like it. It's what we had discussed over a year ago and it makes sense to me. For context, I proposed this setup internally before. The beginning of Qt 5's development made most of the proposal temporarily mute. It is now a good time to pick up the discussion out here in the open ;-) João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting up time-based releases for the project
Thiago Macieira wrote: One think I'd like to know from others is: what does dripping-bucket contain when changes are not going in, in-between releases? From the description and from the graph, it sounds like that branch contains the next release before it is tested out. That is, it's a branch that is in a state of Release Candidate all the time because the final notches on the actual release haven't been done. Experience so far shows that there are always show-stoppers that need to get fixed in the release branch before we can get a release out. These are caught in the release branch because that's when changes get the most widespread testing and issues are bound to be found. And that's another important aspect I did not mention in the original post and which is worth mentioning. Fire-hose is a development branch, things may be variously broken at all times. Typically, developers in this mailing list will be tracking that branch. Leaky-faucet is deemed beta quality and somewhat more stable. At the very least it shouldn't break as often. We can expect that more people will be willing to track this branch with their own development. Dripping-faucet is the stable branch. Anyone who can live out of a git repository (as opposed to packaged releases) will track this branch by default. The biggest blunders will hopefully have been fixed by the time changes reach this branch. In this setup stability also equates to exposure and thus incoming bug reports. If we move the release testing onto leaky-faucet, then dripping-bucket contains only the latest release, with at most a critical patch or two. That depends on whether we consider that typical patch release traffic has an impact on release readiness. (Can bug fixes introduce new regressions? :-) Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting up time-based releases for the project
On segunda-feira, 6 de agosto de 2012 22.13.30, joao.abeca...@nokia.com wrote: Leaky-faucet is deemed beta quality and somewhat more stable. At the very least it shouldn't break as often. We can expect that more people will be willing to track this branch with their own development. One more thing I'd like to add: leaky-faucet should be in the always ready for beta stage. That is, the maintainers of the modules should monitor this branch and ensure that all changes coming in are contributing towards the beta-ready status, not detracting from it. Large code refactorings and new features should be developed out of this branch and merged in only when they're ready to be beta-tested. Whether the beta cycle starts immediately after the feature landing or 6 months later, that's orthogonal to the discussion. -- 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] Setting up time-based releases for the project
On terça-feira, 7 de agosto de 2012 00.20.56, Thiago Macieira wrote: On segunda-feira, 6 de agosto de 2012 22.13.30, joao.abeca...@nokia.com wrote: Leaky-faucet is deemed beta quality and somewhat more stable. At the very least it shouldn't break as often. We can expect that more people will be willing to track this branch with their own development. One more thing I'd like to add: leaky-faucet should be in the always ready And by leaky-faucet, I mean fire-hose. Thanks João for reminding me on IRC. for beta stage. That is, the maintainers of the modules should monitor this branch and ensure that all changes coming in are contributing towards the beta-ready status, not detracting from it. Large code refactorings and new features should be developed out of this branch and merged in only when they're ready to be beta-tested. Whether the beta cycle starts immediately after the feature landing or 6 months later, that's orthogonal to the discussion. -- 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] Setting up time-based releases for the project
On Monday 06 August 2012 21:22:27 joao.abeca...@nokia.com wrote: [...] -+--+-- fire-hose \ \ -+-+--+++-+--++ leaky-faucet \\\\\\ -+-+--+-+--+-+--+-+--+-+--+-+-- dripping-bucket \\\\\\ 5.0.15.0.25.1.05.1.15.1.25.2.0 Let me try to draw that differently, and tell me if I understand it correctly: ---+--+-- fire-hose \ \ --+ +-+++ +-++ leaky-faucet \\\\\\ -+ +-+ +-+ +-+ +-+ +-+ +- dripping-bucket \\\\\\ 5.0.15.0.25.1.05.1.15.1.25.2.0 The difference is that I removed what seems to be merges in your original. There is actually no merges displayed on this graph, Just the branches. The merges are hidden. But if we were to show the merge, it would go from bottom to down, right? Like this: (merges represented by /) ---+--+-- fire-hose / \ / / / / / / / / \ / / / / / / --+ +-+++ +-++ leaky-faucet / \ / / / \ / / / \ / / / \ / / / \ / / / \ -+ +-+ +-+ +-+ +-+ +-+ +- dripping-bucket \\\\\\ 5.0.15.0.25.1.05.1.15.1.25.2.0 Right? I realise not everyone has a decent mail client that shows fixed size font, so there is a link: http://paste.kde.org/530120/ -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting up time-based releases for the project
On terça-feira, 7 de agosto de 2012 01.00.54, Olivier Goffart wrote: ---+--+-- fire-hose / \ / / / / / / / / \ / / / / / / --+ +-+++ +-++ leaky-faucet / \ / / / \ / / / \ / / / \ / / / \ / / / \ -+ +-+ +-+ +-+ +-+ +-+ +- dripping-bucket \\\\\\ 5.0.15.0.25.1.05.1.15.1.25.2.0 I think you're missing the dashes between 5.0.1 and 5.0.2. dripping-bucket is a rolling branch. To make it fast-forward from one release to the next, it needs to merge them. -- 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] Setting up time-based releases for the project
On Mon, 6 Aug 2012 22:13:30 ext joao.abeca...@nokia.com wrote: Fire-hose is a development branch, things may be variously broken at all times. Typically, developers in this mailing list will be tracking that branch. Leaky-faucet is deemed beta quality and somewhat more stable. At the very least it shouldn't break as often. We can expect that more people will be willing to track this branch with their own development. This is the part that I don't quite understand. This makes it sound like Fire- hose is the branch for destabilizing changes. Particularly destabilizing change sets are of course in their own branch, but the large numbers of normally destabilizing changes will make fire-hose mere Alpha quality at best. But then Thiago's email then said that fire-hose should be 'always ready for beta', which seems contradictory. As I interpret it, the bump in quality comes from merging fire-hose to leaky- faucet some time before the release. Unfortunately, I didn't get any extra detail when I zoomed in on your ascii art. Here's my zoomed in version of the diagram: --+- fire-hose \ --+-+--- leaky-faucet \ +--+ dripping-bucket \ 5.1.0 ~2 Months |-| Note that we also seem to disagree on the time scale, but that's what '~' is for ;) . Am I correct in assuming that merging fire-hose to leaky-faucet drops the quality of leaky-faucet to whatever fire-hose may be, and then developer focus shifts to leaky-faucet for stabilization (while destabilizing elements continue to flow rapidly into fire-hose for the next release)? How much lead time do we allocate per release? And what happens if we slip, because we couldn't get it to beta quality in time? If we move the release testing onto leaky-faucet, then dripping-bucket contains only the latest release, with at most a critical patch or two. That depends on whether we consider that typical patch release traffic has an impact on release readiness. (Can bug fixes introduce new regressions? :-) When applied in haste? Roll a d20 :P . More seriously, it sounds to me like dripping-bucket is just there for the release manager to have a further measure of control. But if that's where the packages are generated from, that's where the release testing will happen no matter how few patches we try to accept on top. On a less important aspect, can we use less metaphorical names? master, beta, release perhaps? trunk, stable, release-managers-private-stash? I don't like starting the bike shedding part early, but since your metaphors aren't really working for me I think other names might allow for more clarity. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
