Re: [Development] Looking for Feedback QDeferred
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 QFuture and QFutureInterface.) I suppose this is a very UI-interaction focused, and high-level view on things ;) but it is something that the QFuture/QFutureInterface/QFutureWatcher API supports. 1) I think the chaining/promises style is an improvement to the need to always use QFutureWatcher. We more often need to carry a QFutureWatcher member around than I like (even with a helper function Utils::onResultReady, the moment you need to handle various signals you’ll want to stick to a single QFutureWatcher) 2) We use QFuture/QFutureInterface for a generic progress UI. Basically you tell a central progress UI manager about your QFuture, and that shows a progress bar for it, including a cancel button. What about multiple “subscribers” to a task? The progress UI needs to act on progress info, and finished / success status changes. On a glance I didn’t see if that is possible with your API. I didn’t see cancel functionality in your work, do you have thoughts on this? The implementation for progress seems to be a bit awkward in comparison to QFutureInterface, and doesn’t seem to be separate from the result type? Progress can be pretty separate from actual result producing, i.e. a file system search will be able to provide very fine grained progress information, but might only report a handful of results. Another thing that QtConcurrent handles for us, it to guard against “too much progress reporting”. I.e. if a loop from 1 to 100 reports every single step as progress, this would block the UI/main thread with progress updating. QtConcurrent makes sure that actual progress reporting to the receiving thread only happens in “sensible” intervals. One nice thing about QFuture/QFutureInterface is that one doesn’t actually need to create an _actual_ async task to use the same functionality. We use that at a few places for showing progress for things that are not actually running in a thread, but wait for other asynchronous tasks to finish (e.g. QProcess). But that’s just a convenience that avoids having a separate API for it. 3) Reporting intermediate results is something that we heavily use for things like e.g. the search functionality. While the search is running, you want the UI to already present what was found so far. Br, Eike > On 11. Feb 2019, at 12:49, Juan Gonzalez Burgos 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 > > Thanks. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QDialog vs QPushButton and it's autoDefault default
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 selection and a more complex generic/reusable filter panel (QWidget derived) that can be attached to any table view for complex user side filtering. That panel contains various widgets, including two buttons. I now have tripped painfully over a strange behavior that I could track back to the fact that one of those two buttons was automagically set as the dialog's default button. Now, whenever a user presses to confirm QLineEdit filter input, also the mentioned clear button is activated - causing a fabulous mess. After some research I could explain that unexpected behavior: autoDefault : bool This property holds whether the push button is an auto default button. ... This property's default is true for buttons that have a QDialog parent This also means there is a workaround: I need to call "setAutoDefault(false)" on each button that has the slightest chance to be ever used in a dialog. Everywhere. That is doable but seems very counterintuitive to me. So my questions are: 1. Is this actually how the autoDefault mechanism should work? 2. Why an opt-out instead of an opt-in? 3. Regarding opt-out: Why not restricting the autoDefault default of true to buttons with QDialogButtonBox parents instead of QDialog parents? 4. Anyway, is it good style to change the default value (!) of a property dynamically like this? Thanks in advance! -- Best Regards, Bernhard Lindner signature.asc Description: This is a digitally signed message part ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Looking for Feedback QDeferred
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 client is meant to "own" the QLambdaThreadWorker, therefore sharing the same life-time. If I was gonna batch-process a chuck of data, I would definetively use thread pools to do that in parallel and forget about thread life-time and ownership. As you said it would be faster, less expensive. QLambdaThreadWorker/QDeferred was never meant to be the solution for all threaded problems, just one more tool in your threads toolbox. Thank you for making see that I didn't mention that, I will try to clarify it somewhere. I couldn't agree more with you and that post of function colors. Indeed promises should be a thing from the past, and I also believe co-routines are the solution. But I think they are officially coming until 2020 to C++? (Did I mentioned I am stuck at work using VS2013 compiler?) And how would they interact with Qt? I have seen some experiments here and there: https://blog.qt.io/blog/2018/05/29/playing-coroutines-qt/ http://jefftrull.github.io/qt/c++/coroutines/2018/07/21/coroutines-and-qt.html In the mean time QDeferred has made my life a little bit easier, but indeed I will say goodbye to it when co-routines take over the Qt world! Thanks for the feedback On Mon, Feb 11, 2019 at 8:31 PM Jason H wrote: > 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 thread they could run on. We don't have this > limitation in Qt. I'm on board with easy lambda threading. I'm not on board > with more Promises. > http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ > > > > > *Sent:* Monday, February 11, 2019 at 6:49 AM > *From:* "Juan Gonzalez Burgos" > *To:* development@qt-project.org > *Subject:* [Development] Looking for Feedback QDeferred > 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 > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Looking for Feedback QDeferred
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 thread they could run on. We don't have this limitation in Qt. I'm on board with easy lambda threading. I'm not on board with more Promises. http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ Sent: Monday, February 11, 2019 at 6:49 AM From: "Juan Gonzalez Burgos" To: development@qt-project.org Subject: [Development] Looking for Feedback QDeferred 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 https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New API design for file system operations
> 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 (2004, https://bugs.kde.org/show_bug.cgi?id=88615 ). Anyway, I deleted the library in the application, and ALL my photos went *poof*. I looked in the trash... Nothing. I expected my user-generated data to to be recoverable in the trash. So the use case, is when the user has generated data that the application does not own, where it should not assume ownership of said data and the user has requested it be removed. OR The user has requested the data be removed but not destroyed, so in a way that the data can be potentially recovered. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New API design for file system operations
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 suggest to perform some actions. For example, "moveToTrash" operation might fail for some reason. If you don't have a separate class for trash bin you can only report this error to a user, but neither fix a cause nor do something useful. For example, what if there is not enough space in the trash bin, or what if the trash bin configured to remove files without keeping them and so on... Wouldn't this sort of API useful for a developer who wants to use move-to-trash operation? I see; let’s leave this email threat focused on the file system API discussion, and continue the scoping of the "moving to trash” (and general trash functionality) for the JIRA ticket at https://bugreports.qt.io/browse/QTBUG-47703 :) Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New API design for file system operations
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 some reason. If you don't have a separate class for trash bin you can only report this error to a user, but neither fix a cause nor do something useful. For example, what if there is not enough space in the trash bin, or what if the trash bin configured to remove files without keeping them and so on... Wouldn't this sort of API useful for a developer who wants to use move-to-trash operation? On 2/11/19 1:22 PM, Volker Hilsheimer wrote: 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 simple and complex file operations into QFile and QDir. I agree that creating separate abstraction for file operations is an acceptable option. Although, I don't think that there is should be any difference between "simple"/"complex" or "long"/"short" or "atomic"/"non-atomic" operation in terms of user. As an API user I want to just perform some actions and don't care what is the under the hood; I also want all available operations to be presented in one place based on global classification feature (e.g., "file operation"). Of course, some things like "this is potentially long operation..." should be mentioned in the documentation. Indeed, I don’t want application developers to have to use fundamentally different approaches based on the under-the-hood complexity of the operation. Either do it synchronously, and accept that the calling thread will be blocked; or do it asynchronously, and provide whatever plumbing you might need to have control over the process. I see how my statement above can be misleading; what I wanted to say is that adding an “asynchronous file operations” design to QFile and QDir is cluttery, and instead of adding it there, I’d rather move *all* file system ops into a new class. I also think that we should have a look into some options for file operations from C++ 17: https://en.cppreference.com/w/cpp/filesystem/copy_options . Something similar is worth adding to the new API. Yes, absolutely. A dedicated operations interface that can work with both QFile and QDir (but essentially only cares about file paths) would be nice; that doens’t mean we can’t keep a QFIle API for the simple stuff, ideally one that doesn’t accidentially block your UI event loop because the user selected a 5 GB file for copying. But in this case, QFile and QDir interfaces should be shorten by removing some unnecessary methods. Ideally this operations interface should depend on paths only and shouldn't have any knowledge about QFile and QDir classes. Agree that duplicate functionality in QDir and QFile should become deprecated. Perhaps; overloads that QDir might make sense, as QDir could be seen as a class that operates on a string implementing path semantics in the context of the actual file system (e.g “cdUp” removes the last segment; cd(“foo”) adds “/foo” if foo exists). So, it provides perhaps at least input validation. Hard to make a point for using QFile in the APIs though, at least not as input. For the last point: Moving a file to a trash is something an application would want to do (for previous versions of saved files, for instance; for old save-games; for old downloads; for deleted workspaces etc); I absolutely see the usecases here. But I see no value in an API that provides comprehensive access to the system trash. Unless you use Qt to build a desktop environment or a file manager, you don’t need any of this. If you do the former, then you have done this already; hello KDE. If you do the latter, then that code should be in your app, and not in everyone’s Qt library. Ok, I see your point. But imagine the situation when you need to restore a file from the trash, or get list of files in the trash, or check a space in the trash, or cleanup the trash... Wouldn't it be more convenient to have a separate class for all of this operations? In might be useful even if you have a separate operation for moving files to the trash, because you can make an operation undoable but the thing is that your program is not an exclusive owner of files. The trash bin can be re-created/moved/removed and so on. How would you locate your files in this case? 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. Cheers, Volker On 2/8/19 11:08 PM, Volker Hilsheimer wrote: On 8 Feb 2019, at 10:43, Vitaly Fanaskov mailto:vitaly.fanas...@qt.io>> wrote: On 2/7/19 5:03 PM,
Re: [Development] Looking for Feedback QDeferred
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 bit too specialised for that level of abstraction. Triggering work through a timer is nice, but being able to start the async work based on a variety of triggers (events or signals) would be even nicer :) For instance, starting a database query in response to an HTTP request; or some heavy computation based on changes to the file system. Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New API design for file system operations
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 simple and complex file operations into QFile and QDir. I agree that creating separate abstraction for file operations is an acceptable option. Although, I don't think that there is should be any difference between "simple"/"complex" or "long"/"short" or "atomic"/"non-atomic" operation in terms of user. As an API user I want to just perform some actions and don't care what is the under the hood; I also want all available operations to be presented in one place based on global classification feature (e.g., "file operation"). Of course, some things like "this is potentially long operation..." should be mentioned in the documentation. Indeed, I don’t want application developers to have to use fundamentally different approaches based on the under-the-hood complexity of the operation. Either do it synchronously, and accept that the calling thread will be blocked; or do it asynchronously, and provide whatever plumbing you might need to have control over the process. I see how my statement above can be misleading; what I wanted to say is that adding an “asynchronous file operations” design to QFile and QDir is cluttery, and instead of adding it there, I’d rather move *all* file system ops into a new class. I also think that we should have a look into some options for file operations from C++ 17: https://en.cppreference.com/w/cpp/filesystem/copy_options . Something similar is worth adding to the new API. Yes, absolutely. A dedicated operations interface that can work with both QFile and QDir (but essentially only cares about file paths) would be nice; that doens’t mean we can’t keep a QFIle API for the simple stuff, ideally one that doesn’t accidentially block your UI event loop because the user selected a 5 GB file for copying. But in this case, QFile and QDir interfaces should be shorten by removing some unnecessary methods. Ideally this operations interface should depend on paths only and shouldn't have any knowledge about QFile and QDir classes. Agree that duplicate functionality in QDir and QFile should become deprecated. Perhaps; overloads that QDir might make sense, as QDir could be seen as a class that operates on a string implementing path semantics in the context of the actual file system (e.g “cdUp” removes the last segment; cd(“foo”) adds “/foo” if foo exists). So, it provides perhaps at least input validation. Hard to make a point for using QFile in the APIs though, at least not as input. For the last point: Moving a file to a trash is something an application would want to do (for previous versions of saved files, for instance; for old save-games; for old downloads; for deleted workspaces etc); I absolutely see the usecases here. But I see no value in an API that provides comprehensive access to the system trash. Unless you use Qt to build a desktop environment or a file manager, you don’t need any of this. If you do the former, then you have done this already; hello KDE. If you do the latter, then that code should be in your app, and not in everyone’s Qt library. Ok, I see your point. But imagine the situation when you need to restore a file from the trash, or get list of files in the trash, or check a space in the trash, or cleanup the trash... Wouldn't it be more convenient to have a separate class for all of this operations? In might be useful even if you have a separate operation for moving files to the trash, because you can make an operation undoable but the thing is that your program is not an exclusive owner of files. The trash bin can be re-created/moved/removed and so on. How would you locate your files in this case? 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. Cheers, Volker On 2/8/19 11:08 PM, Volker Hilsheimer wrote: On 8 Feb 2019, at 10:43, Vitaly Fanaskov mailto:vitaly.fanas...@qt.io>> wrote: On 2/7/19 5:03 PM, Volker Hilsheimer wrote: Hi all, TL;DR; we are considering moving file system operations from QFile into a seperate class (or set of classes) for a more consistent and flexible way of moving, copying etc files and directories. The conversation around the design and implementation of an API to move file or directory to the trash in https://bugreports.qt.io/browse/QTBUG-47703 has during the last days moved somewhat beyond that rather straight-forward task, and has become a broader discussion around making file operations accessible outside of the existing set of classes. […] Hi, I've read QTBUG-47703 very carefully and I think that adding some file managers is overkill in this particular case. I would suggest the
Re: [Development] Looking for Feedback QDeferred
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 between the two clear. But that's just my 2 cents. Cheers, Elvis Den mån 11 feb. 2019 kl 12:50 skrev Juan Gonzalez Burgos : > > 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 > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Looking for Feedback QDeferred
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 https://lists.qt-project.org/listinfo/development
[Development] Fix potentially breaking binary compatibility, what can be done?
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 is that this is potentially affecting binary compatibility. What is the right way forward? The patch is here: https://codereview.qt-project.org/#/c/252493/ Thanks, -- Paul Lemire | paul.lem...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New API design for file system operations
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 for file operations is an acceptable option. Although, I don't think that there is should be any difference between "simple"/"complex" or "long"/"short" or "atomic"/"non-atomic" operation in terms of user. As an API user I want to just perform some actions and don't care what is the under the hood; I also want all available operations to be presented in one place based on global classification feature (e.g., "file operation"). Of course, some things like "this is potentially long operation..." should be mentioned in the documentation. I also think that we should have a look into some options for file operations from C++ 17: https://en.cppreference.com/w/cpp/filesystem/copy_options . Something similar is worth adding to the new API. A dedicated operations interface that can work with both QFile and QDir (but essentially only cares about file paths) would be nice; that doens’t mean we can’t keep a QFIle API for the simple stuff, ideally one that doesn’t accidentially block your UI event loop because the user selected a 5 GB file for copying. But in this case, QFile and QDir interfaces should be shorten by removing some unnecessary methods. Ideally this operations interface should depend on paths only and shouldn't have any knowledge about QFile and QDir classes. For the last point: Moving a file to a trash is something an application would want to do (for previous versions of saved files, for instance; for old save-games; for old downloads; for deleted workspaces etc); I absolutely see the usecases here. But I see no value in an API that provides comprehensive access to the system trash. Unless you use Qt to build a desktop environment or a file manager, you don’t need any of this. If you do the former, then you have done this already; hello KDE. If you do the latter, then that code should be in your app, and not in everyone’s Qt library. Ok, I see your point. But imagine the situation when you need to restore a file from the trash, or get list of files in the trash, or check a space in the trash, or cleanup the trash... Wouldn't it be more convenient to have a separate class for all of this operations? In might be useful even if you have a separate operation for moving files to the trash, because you can make an operation undoable but the thing is that your program is not an exclusive owner of files. The trash bin can be re-created/moved/removed and so on. How would you locate your files in this case? On 2/8/19 11:08 PM, Volker Hilsheimer wrote: On 8 Feb 2019, at 10:43, Vitaly Fanaskov mailto:vitaly.fanas...@qt.io>> wrote: On 2/7/19 5:03 PM, Volker Hilsheimer wrote: Hi all, TL;DR; we are considering moving file system operations from QFile into a seperate class (or set of classes) for a more consistent and flexible way of moving, copying etc files and directories. The conversation around the design and implementation of an API to move file or directory to the trash in https://bugreports.qt.io/browse/QTBUG-47703 has during the last days moved somewhat beyond that rather straight-forward task, and has become a broader discussion around making file operations accessible outside of the existing set of classes. […] Hi, I've read QTBUG-47703 very carefully and I think that adding some file managers is overkill in this particular case. I would suggest the following changes: 1. Extract an abstract class (i.e., interface) for common file operations 2. Both QFile and QDir should implement this interface 3. Unify QDir API, e.g., QDir::remove -> QDir::removeFile, in order to match newly-extracted interface 4. Add a separate class which represents system trash bin and contains appropriate methods (e.g., functionality to check files inside, restore files, empty trash etc.) Also in my point of view, it's not necessary to introduce a new method like "moveToTrash". We can extend method "remove" adding a new parameter that might be either a bool flag or some enum. Hi Vitaly and Tor Arne, 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. Looking at the documentation, QFile is an interface for reading from and writing to files; QDir provides access to directory structures and their contents. I’d like it if they were simple interfaces focusing on those specific tasks. But in addition, they provide a mix of file path operations (ie purely string operations), and a subset of operations that affect the file system. There’s some duplication, and little consistency.
