> The question for me is: why would an application (that is not a file
> explorer) want to do any of this? I honestly don’t see the use case.
When I filed the bug against KIO not having a "trash" feature it was because I
was working in digikam (photo library) in KDE - this is MANY years ago
What are the costs of thread start-up?
Why is this not a QRunnable (In my experience Runnables start faster than treads - though it may be anecdotal)
How does it interact with thread pools?
I cringe when I see Promises in 2019. Node/JS uses them because they (until recently) only had one
Maybe I should clarify that QLambdaThreadWorker/QDeferred was designed with
an specific use-case, namely mid/long-term living threads.
For example, a long-living network client in a request/response cycle, or a
class constantly handling time-consuming file operations, etc.
The class to handle that
Hi!
I just experienced same strange behavior of QPushButton. I want to kindly ask
for some
explanations.
I wrote a QDialog derived dialog. That dialog has a standard QDialogButtonBox
with
"Accept" and "Close" buttons. It also has various other widgets, especially a
table view
for item
Hi,
Looking at it with the “Qt Creator” hat on, i.e. with the mindset of “could we
replace what we do in Qt Creator with our extension of QtConcurrent".
(http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/runextensions.h
adds the convenience and actual runnable based around
Hi Volker,
The question for me is: why would an application (that is not a file explorer)
want to do any of this? I honestly don’t see the use case.
I think in order to provide a user some useful information or suggest to
perform some actions. For example, "moveToTrash" operation might fail for
On 11 Feb 2019, at 16:07, Vitaly Fanaskov
mailto:vitaly.fanas...@qt.io>> wrote:
Hi Volker,
The question for me is: why would an application (that is not a file explorer)
want to do any of this? I honestly don’t see the use case.
I think in order to provide a user some useful information or
On 11 Feb 2019, at 12:49, Juan Gonzalez Burgos
mailto:juangbur...@gmail.com>> wrote:
Hi guys,
Sorry to bother you with yet another promise/deferred library for Qt. I am
looking for feedback.
https://github.com/juangburgos/QDeferred
I like it!
The start/stopLoopInThread seems to me to be a
Hi Volker,
Making QFile::remove(bool toTrash=false); is tempting, but I think Thiago has a
valid point about providing a dedicated file system operation abstraction,
rather than cramming a mix of simple and complex file operations into QFile and
QDir.
I agree that creating separate abstraction
Hi,
I've realized we had an issue in Qt3D Input where QMouseEvent and
QWheelEvent' key modifiers property can only actually contain a single
modifier value.
I've made a change to fix this, essentially transforming an enum into a
QFlag, like it should have been right from the start.
The problem
Hey Vitaly,
See inline.
On 11 Feb 2019, at 11:42, Vitaly Fanaskov
mailto:vitaly.fanas...@qt.io>> wrote:
Making QFile::remove(bool toTrash=false); is tempting, but I think Thiago has a
valid point about providing a dedicated file system operation abstraction,
rather than cramming a mix of
Hi guys,
Sorry to bother you with yet another promise/deferred library for Qt. I am
looking for feedback.
https://github.com/juangburgos/QDeferred
Thanks.
___
Development mailing list
Development@qt-project.org
Looks nice! From an API perspective I would call the provider APIs
fail(...) and succeed(...) instead of reject(...) and resolve(...),
and the corresponding consumer APIs onSucceeded(...) and onFailed(...)
(or whenSucceeded(...) / whenFailed(...)). Or something else that
makes the connection
13 matches
Mail list logo
