BTW, have you checked if the thumbnails are still generated for non-removable but encrypted filesystems? My whole system is encrypted (except for /boot), so it would be a performance loss if no thumbnails were ever cached.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Sep 5 2020
Aug 23 2020
Jun 29 2020
for (Device device: list) { StorageAccess *storageAccess = device.as<StorageAccess>(); if (canonPath.startsWith(storageAccess->filePath()) && storageAccess->filePath().size() > match_length) { match_length = storageAccess->filePath().size(); match = device; }
May 9 2020
Use Solid and ask it if the device is on an encrypted device. If Solid does not have such an API, add it.
May 3 2020
Mar 16 2020
In D27804#621988, @sitter wrote:In D27804#621970, @thiago wrote:Still want to see that round-trip.
But why? Converting an smbcUrl to a QUrl would literally be useless code.
Mar 4 2020
Still want to see that round-trip.
looks good to me.
Mar 3 2020
STD3 also forbids domain labels ending in dash, so can you add a test for smb://[fe80::]/ too? You'll need to adjust your code
Looks good, but testing should be extended. I suggest:
Feb 18 2020
Yes, it's been supported for years.
Dec 14 2019
Good catch.
Sep 17 2019
This really needs to be fixed in Qt. 5.13.1 has an overhaul of the system, please make sure that the patch is still required there and does not make things worse.
Aug 23 2019
QFile::copy already implements FICLONE, sendfile() and Darwin's clonefile().
Jun 16 2019
Not endian-dependent, like the memcpy solution. Make sure the other side is adapted to match.
+1
Jun 5 2019
Is anyone working on the ability to open a new profile? I ask this because I had a shortcut assigned to open a root shell (Ctrl+Alt+R) and was quite surprised to find out that it didn't work anynore with no way to get it back. This is not the same as opening a new tab and switching profiles, since that won't change the command that was started.
May 24 2019
As for truncating UTF-8 multibyte sequences in the middle, when you convert back using QFile::decodeName, it'll be nonsensical. But I don't think it really matters since you're truncating and using the display string anyway, so you're already losing data. This wasn't a recoverable conversion anyway.
I cringe a little when you apply QFile to a URL, but this is probably safe enough.
Feb 24 2019
This new backtrace *is* a stuck application. Please report the issue to Mesa (dri/i965). Cc me, I can walk three paces in the office to the Mesa devs and help them figure out what's happening.
I repeat: there's no indication in the backtrace that it is stuck. What's your evidence that it is? You wrote an application that shows nothing and never exits. Now it showed nothing and didn't exit. That's not stuck, that's the expected behaviour.
This last backtrace does not show anything stuck. Thread 1 was actively running, in fact (it's inside of malloc).
Feb 23 2019
The patch is innocuous. I don't see *how* it can solve anything, though, because I don;'t know what DrKonqu::cleanup does.
Feb 20 2019
It looks good to me.
Much better, thanks.
Feb 19 2019
Dec 29 2018
qhelpgenerator is coming back in 5.12.1. You may simply tell people to skip the .0 release and upgrade.
Jul 25 2018
In D14302#297515, @dfaure wrote:The idea of the old code was: if I can't get the lock, then someone else is already in the process of starting kdeinit, so I'll just wait for that to happen, by locking again, i.e. blocking on purpose, and then checking that the DBus name is up, i.e. the other process did manage to do it successfully.
Jul 24 2018
In D14302#297159, @jtamate wrote:(gdb) disass Dump of assembler code for function _ZN9QLockFile7tryLockEi: 0x00007f54be8bc752 <+2>: mov $0xffffffff,%eax ... 0x00007f54be8bc76d <+29>: test %esi,%esi ... 0x00007f54be8bc772 <+34>: cmovs %eax,%esi ... 0x00007f54be8bc78c <+60>: movslq %esi,%rsi 0x00007f54be8bc78f <+63>: callq 0x7f54be962150 <QDeadlineTimer::QDeadlineTimer(long long, Qt::TimerType)>
Quickly checking on openSUSE Tumbleweed
This is indeed Forever. How did it get there?
Can you print the contents of the timer object inside tryLock()?
In D14302#296671, @jtamate wrote:Another hypothesis:
QDeadlineTimer::QDeadlineTimer(qint64 msecs, Qt::TimerType type) Q_DECL_NOTHROW : t2(0) { setRemainingTime(msecs, type); }As t1 is not initialized and QDeadlineTimer::setPreciseRemainingTime only add to t1, it could be any value instead of 0?.
Should I open a Qt bug?
Quick testing via gdb:
In D14302#296479, @dfaure wrote:I agree about tryLock(0) should return immediately, tryLock(-1) should block forever -- I wrote that code and that docu ;-)
Thiago wrote QDeadLineTimer later on though, and ported QLockFile to it. Thiago, any input?
Apr 8 2018
Feb 3 2018
That doesn't make sense. There's QFile::encodeName in the code.
Looks good.
The patch that I can see accomplishes what the description says it should do. And I agree with the idea of the patch.
Why do you ask for a rewview then not wait for the review?
Aug 8 2017
Jul 15 2017
This class isn't hooked up to anything. It's technically correct as an FD sender and receiver. What I want to see is how you use it, because that's extremely important to get right.
Jul 3 2017
Qt 5.10 will have QFileInfo::birthTime too.
May 30 2017
In D5972#112994, @rjvbb wrote:Yes, here too, haven't had time to read back up on and go through the whole Qt code review process. What branch should I target, anyway?
Makes sense to work around older versions of Qt without the fix.
In D5865#112747, @rjvbb wrote:In D5865#112743, @thiago wrote:Fix the source code.
If certain third-party libraries can't compile under MSVC 2015 (or even 2017!) with default compiler options, they don't deserve to be used. Blacklist them.
That may work for Qt but is not an acceptable attitude for ECM, IMHO - and MSVC is problematic enough to build KF5 code for other reasons not to jump through hoops for it. You cannot expect FOSS projects to avoid Boost because it uses less common feature of the standard, big ole bad M$ cannot be bothered to write a proper compiler. I'd be all for blacklisting such compilers, if anything had to be blacklisted.
May 29 2017
In D5865#112737, @rjvbb wrote:In D5865#112697, @thiago wrote:Why are we spending time in named operators? It's much easier to fix the source code not to use them and then the problem goes away.
This is about adding a convenience macro for projects that have dependencies using named operators, like certain Boost modules.
In D5865#112679, @rjvbb wrote:That option only exists in MSVC 2017.
Should we have deduce that from the docs I cite in the CMake comments? I'm willing to believe that I misread as far as support for named operators is concerned, but they do mention 2015 Update 3 specifically as the appearance of /permissive-.
In D5865#112549, @rjvbb wrote:If a compiler is problematic in general it may not be worth it trying to account for it in a macro, trying to coerce it into doing something it cannot handle. I don't think that's a reason not to implement the macro at all though. Even if we cannot figure out from what version onwards the /fpermissive- option works it could still be useful for cross-platform code that really needs named operator support to let the macro print a warning (or raise an error) when it is built with MSVC.
Dec 16 2016
In D2545#69187, @kfunk wrote:In D2545#69091, @thiago wrote:There doesn't seem to be a way of doing some clean up before the threads are forcibly killed.
Maybe if I abuse qtmain().
This would only fix it for non-console GUI applications if I understand correctly. That's what we have here, but we'd still keep console applications buggy. There's no way to inject code before ExitProcess() with a plain console application.
More information on this Windows behaviour:
In D2545#69083, @kfunk wrote:Here's the other problem: it's possible for threads to simply disappear on Windows. Given that I see "dllmain" in the backtrace (though not DllMain), I can't rule out that this has happened. Qt 5.6 has a workaround to another deadlock caused by Windows. Can you try to cherry-pick 3ec57107cedb154f256e3ad001ea5475cc64fa94 from 5.8?
With 3ec57107cedb154f256e3ad001ea5475cc64fa94 applied: Still dead-locking, same backtrace.
Dec 3 2016
In D2545#66904, @thiago wrote:Commit ad66dbe305cff72443f4d3484191872d56e6dfbb in qtbase did try to solve this by disconnecting the senders when the objects were getting deleted. closeConnection() is called before the thread exits (from QDBusConnectionManager::run), so I don't know how there's still a BlockingQueuedConnection active.
Is it possible that the service began being watched during destruction?
In D2545#66545, @kfunk wrote:In D2545#65976, @dfaure wrote:Actually, I think Thiago's still waiting for a backtrace of all threads.
I think I've already said this via other channels: There's only one thread left at this point.