| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Add a configuration Option to (de-)select expensive file operations.
That would be md5Summing and gathering the Bitrate/Duration.
That should help the performance on networked directories...
|
| |
|
|
|
|
|
|
|
|
|
| |
Get rid of SmDataCollector and do its job in small, QRunnable tasks and
let QThreadPool manage the treads.
Works well with a local Filesystem. Yet to see how it works over
networked Filesystems.
Ah, before I forget: NEVER, EVER USE QPixmap in THREADS -> Random
crashes! (Yes, I know, it's documented...)
|
| |
|
|
|
| |
This reverts commit 2cc92200386c55818cbe9bcb7d2e488170317d70.
Wrong, non-working solution for this problem.
|
| | |
|
| |
|
|
| |
Show a progress dialog when gathering data from the filesystem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit dbfc4f7bf395bf20aa21058372d47d17d040f553. It was
totally and utterly wrong.
This is what really happened, hopefully:
Since a Semaphore can guard more than a single resource, it could happen
that both mSemUsed and mSemFree were available at the same time. So it
could happen that both the watcher and the datacollector tried to access
the dataqueue at the same time. Since ->dequeue() is not atomic, this
could throw of the internal iterator from the QList, resulting in a
crash.
The solution is simple: Guard it with a shared Mutex.
|
| |
|
|
|
|
|
| |
This reverts commit 06cfadc8386aec27b9c7c43486fc0b057e9fb022.
Turns out that this was not the root cause for the crashes.
Still stumped.
|
| |
|
|
|
|
|
| |
This stuff was racy from the beginning. It could happen that the model
got reset after we fetched the selected indexes. Add a mutex and lock it
before operating on the file view. Hopefully this will many, if not all
random crashes.
|
| |
|
|
|
|
|
|
|
|
| |
Don't try to delete all the prepared statements manually. Get rid of the
~destructors and just close the QSqlDatabase. close() deletes all
Statements.
Also, quit() all QThreads on closeEvent() except CompleterProducer. When
the experimental archive view gets merged, that QThread is gone. No need
to bother...
|
| |
|
|
|
| |
Fetching data sometimes takes a long time, so do it in a QThread and
show a progress dialog. Some kludges included :)
|
| |
|
|
|
| |
Don't delete threads and stuff in destructors. It leads to SIGARBRT when
debugging. Now we get a warning on close, but who cares?
|
| |
|
|
|
| |
Indicate if we already have a file by coloring the filename darkGreen
when browsing the filesystem.
|
| |
|
|
|
|
| |
If file is an image, grab the size and add it to the model.
Also, remove some leftover debug statements from SmTreeView.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A huge commit, I know, but it was definitely worth it! It makes the
homebrew FilesystemModel work! It's divided up into two threads:
1. The Watcher: it reacts on inotify events and dispatches them to:
2. The Collector: this thread gathers the data and emits the SIGNALS to
the the view.
Now we can actually refresh the View, not possible with
QFileSystemModel, and the data reloads in almost real time without
blocking the GUI.
Unfortunately this uncovered some bugs I had to fix:
1. Helper::md5sum: Don't crash if read fails with -1
2. SmTreeModel::addRow is broken. Even after 5h I couldn't figure out
how or why, so I brute forced it. Reset the moded when a file is added.
3. Get rid of a lot of unneeded #include's
I guess that's about it...
|
| |
|
|
|
|
| |
blocking the GUI isn't nice, so use a separate Thread to gather all the
data for SmDirModel. Populating and changing directory works, but
modifying a file is most likely broken.
|
| |
|
|
| |
I think I got it working! It does what I want it to do :)
|
|
|
Gotta take a break here. Hopefully this will end up in a custom
QFilesystemModel, but I'm hitting so many bugs on the way. Some things
haven't worked for ages, I guess.
Anyway, the watcher doesn't do anythying right now, still fixing bugs...
|
