[Development] A bug of Item position in Qt Quick2?
I think this is a bug , hope someone could tell me how to solve this. http://qt-project.org/forums/viewthread/25873/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A bug of Item position in Qt Quick2?
It is not a bug. Try using transformOrigin: Item.TopLeft For questions about usage of Qt, please post to qt-interest (http://lists.qt-project.org/mailman/listinfo/interest) cheers, Gunnar On Mar 20, 2013, at 10:24 AM, hailong geng longlon...@yahoo.com wrote: I think this is a bug , hope someone could tell me how to solve this. http://qt-project.org/forums/viewthread/25873/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] consistentTiming vs. wayland animation speed
Hi, when using qtwayland as client server, then currently the animation speed is way too high (~6x what it should be on my machine) (got reported by at least one other person in #qt-lighthouse) I've dug a little bit and found that: BufferQueueingOpenGL (QPlatformIntegration::Capability) is enabled for wayland, which triggers: QUnifiedTimer::instance(true)-setConsistentTiming(true); (see QQuickWindowManager::instance()) Which results in a fixed(!) 'delta' (animation progress 'time') of, in my case 16, BUT the 'proceed'** isn't done every 16ms, but rather every ~1ms. If using weston the 'proceed'** is called every ~10-12ms, which is still wrong, but way closer then ~1ms ... that's why weston looks ok but qtcompositor looks broken. **QUnifiedTimer::updateAnimationTimers I'm not sure where to problem originates from and how to fix it ... My current guess is: bool QQuickRenderThreadSingleContextWindowManager::event(QEvent *e) with (e-type() == QEvent_Sync) is called way to often. It should be called every 16ms (as close as possible) ... shouldn't it? Can any elaborate what's the use-case for consistent-timing and how it's supposed to work? Greets Thomas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QA] Suggestion -- Setting Up the Priority in JIRA
On 03/18/2013 12:45 PM, Knoll Lars wrote:
On 3/14/13 1:00 PM, Jason McDonald macadd...@gmail.com wrote:
On Wed, Mar 13, 2013 at 11:48 PM, Anttila Janne janne.antt...@digia.com
wrote:
Jason McDonald wrote:
On Wed, Mar 13, 2013 at 2:42 AM, Thiago Macieira
thiago.macie...@intel.com wrote:
On terça-feira, 12 de março de 2013 13.28.37, Motyka Rafal wrote:
Hello,
I want to suggest another change for JIRA: - A Reporter should be
able
to set the Priority starting from the Create Issue window. -
Guidelines for setting Priority should be provided (already working
today).
Please feel free to comment on this. If there are no serious
objections, this change will be introduced soon. The impact of the
change will be evaluated.
I disagree. The priority should be set by the triager, the person who
can make a dispassionate, objective assessment of the bug's priority.
The bug reporter is way too involved to make that assessment.
When we first introduced Jira, we allowed the priority field to be set
by the reporter, and this resulted in me spending rather a lot of time
turning P0's and P1's into P3's and P4's. Before long my boss decided
to hide the priority field from the Create Issue form. I don't know
whether the climate has changed enough since then for it to be
reasonable to expect a different result if we were to put the priority
field back in the form.
Would it be possible to bring priority field back for certain JIRA
roles,
if not for everyone?
Sure, approvers and maintainers were not the source of the problem.
The grossly exaggerated priorities mostly came from Qt users (as
opposed to those developing Qt) and from a subset of Nokia's QA
contractors.
We could certainly benefit from better initial information on the bug. The
way to solve this could be to use some sort of questionnaire during the
creation of the bug (does it cause crashes, do you have a workaround,
etc.) and compute an initial priority depending on the answers.
Still I think we need to make it easy for people to get 'bug evaluation'
privileges in Jira without requiring them to be Approvers. So a group for
people with somewhat extended Jira editing rights would be a good thing
IMO.
Cheers,
Lars
The idea of allowing everyone to set priorities for bugs originally
sounded risky to me, but the more I think about and discuss the
alternatives, the better it sounds. I'm going to propose something:
Everyone with a Qt Project Jira account can set the priority for a
*bug*; suggestions should probably not have a priority field at all. The
importance of a suggestion can be determined by the amount of
voters/watchers.
The Create Issue form (when creating an issue of type Bug) is altered
like so (* = mandatory):
Summary *
Affects Version/s *
Component/s *
Compilable, reproducible example * (was Description, has text under
the field name that says Please use {code}{code} tags to provide code
samples or attach files below. Click the (?) icon for formatting help.)
Tested environments * (as opposed to just Environment - this makes it
clear that only the listed environments were tested by the reporter and
that others could be affected)
Causes a crash * (checkbox)
Is a regression * (checkbox)
Latest known working version (shown/enabled if Is a regression is
checked)
Has a workaround * (checkbox)
Workaround (shown/enabled if Has a workaround is checked)
Priority * (has text under the field name that says Please click the
(?) icon for an explanation of which priority is appropriate for this bug.)
Assignee
Attachment
Each new field (where it's not already mentioned) would of course need
accompanying help text/a help icon describing the field.
Renaming the Description field to Compilable, reproducible example
is not going to stop people from providing too little information to
reproduce the bug, unfortunately. I feel that this is more important
than the issue of untriaged bugs. More time is wasted by trying to
reproduce something than setting the priority after a quick glance of
the reported negative effects of a bug.
Cheers.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QA] Suggestion -- Setting Up the Priority in JIRA
On Wed, Mar 20, 2013 at 12:05:31PM +0100, Mitch Curtis wrote: The idea of allowing everyone to set priorities for bugs originally sounded risky to me, but the more I think about and discuss the alternatives, the better it sounds. I'm going to propose something: I see your proposition, but I would like if you would explain what it would improve, the motivation behind it. For me the priority is only valuable if all bugs are triaged according to the same scale. For emotional reason, no user is going to bother filling a bug report and set it to low priority. Since a big share of bug reports are reported by user, that means that part of the bug will be reported with a scale of P1-to-P5 as reference, while the rest will use a compressed P1-to-P3 scale. I like the idea that a group of tightly connected people do the triaging for that reason. Everyone with a Qt Project Jira account can set the priority for a *bug*; suggestions should probably not have a priority field at all. The importance of a suggestion can be determined by the amount of voters/watchers. Votes are a user pulse tool, priority is a project management tool. For example, if for one suggestion a paying voter is giving the assignee 10x more $$$ than all the rest of the voters on a different suggestion, the assignee will probably want to track the high-revenue suggestion as more important. So I think that importance is also relevant for suggestions. I'm saying all this without knowing what you would like to improve, so this might be slightly irrelevant. Cheers, Jocelyn ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QA] Suggestion -- Setting Up the Priority in JIRA
On 03/20/2013 12:53 PM, Jocelyn Turcotte wrote: On Wed, Mar 20, 2013 at 12:05:31PM +0100, Mitch Curtis wrote: The idea of allowing everyone to set priorities for bugs originally sounded risky to me, but the more I think about and discuss the alternatives, the better it sounds. I'm going to propose something: I see your proposition, but I would like if you would explain what it would improve, the motivation behind it. For me the priority is only valuable if all bugs are triaged according to the same scale. For emotional reason, no user is going to bother filling a bug report and set it to low priority. Since a big share of bug reports are reported by user, that means that part of the bug will be reported with a scale of P1-to-P5 as reference, while the rest will use a compressed P1-to-P3 scale. I like the idea that a group of tightly connected people do the triaging for that reason. Perahps I should have sent my proposal as a separate email, as it's not at all dependent on the user being able to set the priority. I'm less bothered by whether or not users can set priority than whether or not they create useful bug reports. When I'm looking at an untouched bug, the biggest issue is whether or not I'm able to reproduce it; determining the priority is almost always easy. My proposal aims to encourage the creation of useful bug reports where the only thing that needs to be done by someone trying to determine whether it is valid or not (which is separate from setting the priority) is copy the code from the report into Creator and run it. Like I said, making certain fields mandatory won't stop *everyone* from creating less-than-useful bug reports, but it helps. The fields that I stole from Lars' suggestions (regression, workaround) related to the questionnaire are useful regardless of whether the user can set the priority and I don't think that they need to be explained. Everyone with a Qt Project Jira account can set the priority for a *bug*; suggestions should probably not have a priority field at all. The importance of a suggestion can be determined by the amount of voters/watchers. Votes are a user pulse tool, priority is a project management tool. For example, if for one suggestion a paying voter is giving the assignee 10x more $$$ than all the rest of the voters on a different suggestion, the assignee will probably want to track the high-revenue suggestion as more important. So I think that importance is also relevant for suggestions. I'm not so sure that someone being *payed* to implement a suggestion should be relying on a publically available priority field in Jira to track their work. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QA] Suggestion -- Bug Report Description Template
On 02/28/2013 08:50 AM, Mitch Curtis wrote: On 02/19/2013 03:33 PM, Motyka Rafal wrote: [...] I would love for this to get some traction. It gets really repetitive asking for examples from the same people all the time. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development My proposal for changes to the Create Issue form: http://lists.qt-project.org/pipermail/development/2013-March/010461.html ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] WindowSystemEvent accepted status
There are cases where the platform plugin needs to block and check if Qt accepts an event or not: - ShortcutOverride: tryHandleShortcutEvent is synchronous (uses QGuiApplicationPrivate:: shortcutMap directly) and returns a bool. - CloseEvent: The platform needs to know if Qt cancels the close. - The general embedded Qt case: Qt is a view embedded in an application. Key and mouse events should be propagated to the the application if Qt does not accept them. We can already flush the event queue by calling flushWindowSystemEvents(), but getting the accepted status is not possible. Proposal: (for dev/5.2) - Add bool accepted to WindowSystemEvent. - Make all QWindowSystemInterface::handleFooEvent functions return a WindowSystemEvent pointer. - The returned WindowSystemEvent is owned by QWindowSystemInterface and will be deleted later. - Make all QGuiApplicationPrivate::processFooEvent functions set the accepted status. - All events should go through QWindowSystemInterfacePrivate::handleWindowSystemEvent. Don't call QGuiApplication directly. The pattern for getting the accepted status then becomes: QWindowSystemInterface::WindowSystemEvent *event = QWindowSystemInterface::handleFooEvent(…) QWindowSystemInterface::flushWindowSystemEvents(); // use event-accepted immediately after calling flushWindowSystemEvents(); Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Stepping down as maintainer, putting new people on board.
+1 to everything Hugo said. On Tue, Mar 19, 2013 at 3:49 PM, Hugo Parente Lima hugo.l...@openbossa.org wrote: Hi, Following what's described on Qt Governance Model I'm sending this e-mail to step down as maintainer of PySide and to propose/nominate new approvers and a new maintaner. Me and Marcelo Lira are not working with with PySide anymore, so the better we can do is to pass the token to someone able to continue the work, so I'm also sending this e-mail on behalf of Marcelo Lira that is also stepping down the maintainer role from PySide project. Before quit I would like to propose John Ehresman as the new maintainer and Roman Lacko and John Cummings as approvers. Both John's have been contributing to PySide with bug fixes since we slow down the PySide development, Roman Lacko is doing a great job on PySide Microsoft Windows releases plus fixing bugs related to the MS platform since the Nokia times. The funny part is that I'm writing this e-mail wearing a old PySide t-shirt. -- Hugo Parente Lima -- Marcelo Lira dos Santos INdT - Instituto Nokia de Tecnologia ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [IMPORTANT] staging in qt dev branches temporarily disabled
moin, empirical evidence shows that People™ don't read announcments, and consequently are still staging changes meant for 5.1 (i.e., bugfixes to new functionality) to dev. these changes would miss 5.1, or need to be cherry-picked, both of which are bad. consequently i have temporarily locked down the relevant branches, so really *everyone* gets it (i.e., is forced to ask wtf is going on). unfortunately this also prevents staging changes which are legitimately meant for dev. the solution/workaround is simple: just add me or Sergio Ahumada to the reviewers and ask for staging. i don't think this will be a real bottleneck, but in case it turns out to be one, we can quickly create a new group with people who are confirmed to be well-informed about the state of affairs. the lock can be removed on friday evening, i think. at least i hope all integrations are done and everyone got that by this time. sorry for the inconvenience. hack on! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Updating third-parties
Hello We're feature-freezing 5.1. It's time to verify if any of the third-party libraries we include in Qt need updating to newer versions. I recommend updating all of them to their latest versions. Do we have volunteers? Listing of third-party libraries (high-priority items marked with *): qtbase: ANGLE (*) ATSPI2 DES Easing equations Freetype (*) Harfbuzz IAccessible2 libjpeg (*) libpng (*) MD4 MD5 PCRE (*) pixman SHA-1 SHA-2 SHA-3 Sqlite (*) Wintab XCB zlib (*) qtimageformats: libmng libtiff qtjsbackend: V8 qtscript: JavaScriptCore -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] [IMPORTANT] staging in qt dev branches temporarily disabled
On quarta-feira, 20 de março de 2013 15.53.38, Oswald Buddenhagen wrote: empirical evidence shows that People™ don't read announcments, and consequently are still staging changes meant for 5.1 (i.e., bugfixes to new functionality) to dev. these changes would miss 5.1, or need to be cherry-picked, both of which are bad. Obviously the bugfixing of stuff that is *only* in dev needs to go to dev, until that content appears on stable too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Updating third-parties
qtbase: Harfbuzz Done. Konstantin 2013/3/20 Thiago Macieira thiago.macie...@intel.com: Hello We're feature-freezing 5.1. It's time to verify if any of the third-party libraries we include in Qt need updating to newer versions. I recommend updating all of them to their latest versions. Do we have volunteers? Listing of third-party libraries (high-priority items marked with *): qtbase: ANGLE (*) ATSPI2 DES Easing equations Freetype (*) Harfbuzz IAccessible2 libjpeg (*) libpng (*) MD4 MD5 PCRE (*) pixman SHA-1 SHA-2 SHA-3 Sqlite (*) Wintab XCB zlib (*) qtimageformats: libmng libtiff qtjsbackend: V8 qtscript: JavaScriptCore -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fixing file dialog performance on Windows
Hi, The file dialog takes up to 30 seconds to be usable if we're listing files on a USB or remote share with 10k files. The bottlenecks are QFileIconProvider::icon(const QFileInfo info) and QFileInfo::isSymLink(). I solved the icon problem by looking them up in the registry, by extension, and caching them. For the isSymLink() issue, I discussed with fkleint and rittk and we kind of agree that we should simply check if the file extension is .lnk, instead of calling GetFileAttributesEx. The Windows native file dialog does not resolve NTFS symlinks, only .lnk, so we would be consistent with it. Any objection? Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090 [2], USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating third-parties
qtimageformats: libmng libtiff libmng is some kind of obsolete, last release is 20030305. I had two patches for libtiff, just not merged in before the BIG merge. Resubmitted to stable branches already. Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Spring-cleaning the Gerrit dashboards, again
Can we please agree on cleaning the dashboards up? Or, if we've agreed, can we do it? My dashboard is unusable. For a few months now, I have stopped my daily look at the Review Requests section. As a result, I have missed important reviews of new features that should maybe be in 5.1, but will probably miss the deadline because my comments come in too late. Tough luck if you were affected. I don't care how we're going to solve this, but can we please agree that we need to solve it and *do* solve it? To be frank, I really don't care if people feel offended that their patch that they haven't updated for 4 months gets abandoned. If someone can find a better word, say so. If someone knows whether it's possible to create a separate state in Gerrit and this person *can* do it in our Gerrit installation within two weeks, say so. Otherwise, let's use the solution we know of. Until that happens, here's how I will operate: - I will look at my Review Requests dashboard once a month, time-permitting This does not mean I will review everything. Complex reviews will probably be skipped. - I will react to pings on IRC (but reserve the right to do it later) - I will react to Gerrit emails that arrive while I am awake When I wake up, there are about 100 unread emails in the Gerrit folder alone, most of which will be ignored If you need my attention and you live in Europe, your best bets are after 18:30 or before 09:00 (CEST; for CET, subtract one hour). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Updating third-parties
On quarta-feira, 20 de março de 2013 09.50.22, Thiago Macieira wrote: We're feature-freezing 5.1. It's time to verify if any of the third-party libraries we include in Qt need updating to newer versions. I recommend updating all of them to their latest versions. Actually, the merges are already happening, so 5.1 *is* feature frozen. Please target your updates to stable if you're updating within minor (non- feature) releases of your third-party or if you're fixing important bugs. Updates for the sake of update should be in dev and will wait for 5.2. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] [IMPORTANT] staging in qt dev branches temporarily disabled
On quarta-feira, 20 de março de 2013 15.53.38, Oswald Buddenhagen wrote: the lock can be removed on friday evening, i think. at least i hope all integrations are done and everyone got that by this time. Thanks for the update, Ossi. I think you forgot to say the most important thing. So I will say it in capital letters so everyone understands: QT 5.1 IS FEATURE FROZEN -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Updating third-parties
Actually, the merges are already happening, so 5.1 *is* feature frozen. Please target your updates to stable if you're updating within minor (non- feature) releases of your third-party or if you're fixing important bugs. Updates for the sake of update should be in dev and will wait for 5.2. The BIG merges for every modules have started, some are finished. Then this Updating notice doesn't have much meaning in this very short periode. I would suggest only important bug fix should go into stable branch. All general updates should happen in dev branch after the frozen. Better to happen 1 or 2 months before next BIG merges, sth like July or August, I guess. Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Spring-cleaning the Gerrit dashboards, again
Hi, On Wednesday 20 March 2013 19:31:17 Thiago Macieira wrote: Can we please agree on cleaning the dashboards up? Or, if we've agreed, can we do it? My dashboard is unusable. For a few months now, I have stopped my daily look at the Review Requests section. As a result, I have missed important reviews of new features that should maybe be in 5.1, but will probably miss the deadline because my comments come in too late. Tough luck if you were affected. I don't care how we're going to solve this, but can we please agree that we need to solve it and do solve it? To be frank, I really don't care if people feel offended that their patch that they haven't updated for 4 months gets abandoned. If someone can find a better word, say so. If someone knows whether it's possible to create a separate state in Gerrit and this person can do it in our Gerrit installation within two weeks, say so. +1, agree completely. Let's just abandom them. It is not like the patch is shredded and lost. The cluttered dashboards are a real problem. In the past, I have removed myself from old reviews, with all the drawbacks that this brings, which we discussed earlier. And I am not even added to many reviewers, I can only imagine how Thiago's situation might look like. So yes, we really need a technical solution for this. Auto-abandoning stale reviews seems to be the easiest short-term solution. A seperate Gerrit state would be an improvement on that. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating third-parties
On 20 March 2013 17:50, Thiago Macieira thiago.macie...@intel.com wrote: PCRE (*) PCRE 8.31 and 8.32 do indeed introduce new features as well as fix various bugs, so I'm a bit undecided whether it's worth including them in stable at this point, although slightly inclined for the inclusion (we won't use the new features; so we will simply benefit from the bugfixes or speed improvements). In any case, planning for the future: surely I will ask for a 8.32 (8.33, perhaps) import in the 5.2 timeframe, and if distributions will have already started including 8.32 before the feature freeze, it's likely that I will submit some QRegularExpression patch that will make Qt *require* 8.32. Thanks, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Spring-cleaning the Gerrit dashboards, again
On Wed, Mar 20, 2013 at 11:31:17AM -0700, Thiago Macieira wrote: Can we please agree on cleaning the dashboards up? Or, if we've agreed, can we do it? i think there was consensus to do it. however, it depends on https://bugreports.qt-project.org/browse/QTQAINFRA-598 to find acceptance, and the work to upgrade to a new gerrit version and do further improvements has started only now. however, this does in no way affect the fact that there are still a lot of changes pending which actually *are* dead, not deferred. so i'd like to urge everyone again to take a honest look at their changes, and also at the changes of drive-by contributors who were never seen again (which, btw, i should do, too ^^). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating third-parties
On quarta-feira, 20 de março de 2013 18.52.40, Qi Liang wrote: Then this Updating notice doesn't have much meaning in this very short periode. I would suggest only important bug fix should go into stable branch. All general updates should happen in dev branch after the frozen. Better to happen 1 or 2 months before next BIG merges, sth like July or August, I guess. Indeed. I'm sorry I sent it today. I was reminded of updating the third- parties today when a colleague here in the office asked me if we bundled zlib and used it, as they're doing some work on it. I at least answered that we don't use our own zlib on sane systems, where the system copy is usually highly optimised. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Spring-cleaning the Gerrit dashboards, again
On Wed, Mar 20, 2013 at 11:31:17AM -0700, Thiago Macieira wrote: Can we please agree on cleaning the dashboards up? Or, if we've agreed, can we do it? i think there was consensus to do it. however, it depends on https://bugreports.qt-project.org/browse/QTQAINFRA-598 to find acceptance, and the work to upgrade to a new gerrit version and do further improvements has started only now. however, this does in no way affect the fact that there are still a lot of changes pending which actually *are* dead, not deferred. so i'd like to urge everyone again to take a honest look at their changes, and also at the changes of drive-by contributors who were never seen again (which, btw, i should do, too ^^). Is there a group or an individual willing to abandon changes on our behalf if the person who submitted is no longer responding to updates in the meantime? I have a couple such changes in my review thing but I don't want to bother people with it as I can imagine it's a tedious process to have to go in and abandon someone else's changes. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fixing file dialog performance on Windows
The file dialog takes up to 30 seconds to be usable if we're listing files on a USB or remote share with 10k files. The bottlenecks are QFileIconProvider::icon(const QFileInfo info) and QFileInfo::isSymLink(). I solved the icon problem by looking them up in the registry, by extension, and caching them. I assume that for executables you look it up directly or is that stored in the registry too? For the isSymLink() issue, I discussed with fkleint and rittk and we kind of agree that we should simply check if the file extension is .lnk, instead of calling GetFileAttributesEx. The Windows native file dialog does not resolve NTFS symlinks, only .lnk, so we would be consistent with it. Any objection? None from me at least, I will be glad to see this issue get resolved after all this time :) Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
