[Development] Nominating Rebecca Worledge for maintainer of Qt Lottie
Hi! In Qt 5.13 we have added a Qt.labs module called "Qt Lottie", with Qt Quick APIs for showing scenes and animations that were exported using the Bodymovin plugin in After Effects. https://codereview.qt-project.org/qt/qtlottie Rebecca Worledge has graciously offered to adopt the maintainership of this module. She has worked for Qt for eight years in our Professional Services organization, providing invaluable work for our customers as well as researching and developing internal prototypes, but this would be her first maintainership in the Qt Project. Thanks, Rebecca! -- Eskil Abrahamsen Blomfeldt Senior Manager, R The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfe...@qt.io http://qt.io The Future is Written with Qt www.qtworldsummit.com ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QDialog vs QPushButton and it's autoDefault default
Hi Volker! Hm, ok, I see. Thanks a lot for the explanations. Turned out the reason why the autoDefault heuristics kicks in is because the accept-role- button is disabled by default (until the user selects an item from the table). So the heuristic takes over a bit to early. To provide a non-auto-default I will need to set the default button programmatically. Still I am not satisfied. People tend to finish text input by pressing Enter, even in dialogs. For dialogs containing a sumplementary line edit (not being the main input of the dialog) this may also trigger some dialog action ahead of time. Is there a good solution to help user avoiding that mistake? I considered not to have a default button at all (neither set programmatically nor selected automatically) but that seems difficult with that always-on heuristics. > The default button gets pressed when the user presses Enter in a dialog, > unless an > autoDefault button has focus, in which case that button will be pressed. > That’s what the > user would expect. > > So, that your button is pressed when focus is in a QLineEdit would suggest > that your > clear button is the next autoDefault button in the focus chain (as per the > documented > behavior, and that there is no default button. Note that when using > QDialogButtonBox, > you only get a default button if one of the buttons in the box has the > “Accept” role - > otherwise you have to make one of the buttons the default button explicitly. > > So to your questions: > > 1) the behavior you are seeing seems to be as it should be, but you might > have to set a > default button for autoDefault heuristics not to take over completely and > cause > confusion. > 2) Opt-out would make it more work to have the kind of UI the user expects > (focused > button is pressed on Enter). > 3) QDialogButtonBox isn’t visible to the user, so a button behavior > differnelty in a > dialog just because it’s laid out in code with the help of QDialogButtonBox > seems > somewhat arbitrary. > 4) Default values of object properties being context dependent is not that > unusual > > > Cheers, > Volker > -- Best Regards, Bernhard Lindner On 11 Feb 2019, at 22:47, Bernhard Lindner wrote: > > > > 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?> > > signature.asc Description: This is a digitally signed message part ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] GSOC 2019
Dear sir, I am Aditya Chondke from India. Currently, I am pursuing Masters in Geoinformatics from CSRE, Indian Institute of Technology Bombay (IITB). I have my bachelors in Computer Science. I have extensive knowledge in C++ and Python and I am very passionate about writing codes in C++. Presently I am studying High-Performance Scientific Computing using C++ and Machine Learning course. I would love to contribute to Qt Project the upcoming Google Summer of Code 2019. I would be very grateful to get any directions to start with so that I can pursue and participate in the Google Summer of Code 2019 with your organization. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] GSoC 2019
Respected Sir, I am Parashuram Shourya from India. Currently, I am doing my Master’s in Geoinformatics from Centre of Studies in Resources Engineering(CSRE), Indian Institute of Technology Bombay(IITB). I have a Bachelor's degree in Computer Science and Engineering. Currently, I am learning Machine Learning and High-Performance Computing. I have vast programming experience in C, C++, Python I would love to contribute to The Qt Project in the upcoming Google Summer of Code 2019. I would be very grateful to get any directions to start with so that I can pursue and participate in GSoC 2019 with your organization. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HDR Support in Qt and Angle
Hi Dmitry, Thanks for all the hard work :) It's not my area, so I won't be able to comment on the patches as such. Please add reviewers to all patches, so they don't get forgotten. While that's quite some work, many people will only see email notifications from gerrit, or look at their dashboards, and it's easy to miss a dependency like that. Cheers, Frederik On tirsdag 5. februar 2019 17:19:29 CET Dmitry Kazakov wrote: > Hi, all! > > I have finally published my HDR patchset in gerrit! It was the first time I > pushed something into gerrit, so if I did something wrongly, please tell :) > > https://codereview.qt-project.org/#/c/252187/ > > There are a few general questions I would like to ask your opinion about: > > 1) Is it okay to list all the available colorspaces in > QSurfaceFormat::ColorSpace? It leads to the fact that qsurfaceformat.h > should be included in quite a lot of places. I wonder if you think it is > okay. > 2) Is API for color space support > (QOpenGLContext::isSurfaceColorSpaceSupported()) actually needed for Qt? > See patch [1]. I first implemented it, but then found that I will have to > do "config probing" anyway. So, technically, this API is not needed for > Krita and HDR implementation, but it might be used as a first-line check by > someone... > 3) Ideally, setTextureColorSpace() method should also be implemented for > QOpenGLWindow. Right now it just defaults to DefaultColorSpace. > 4) Should I add some tests to Qt? If yes, where? > > To test HDR, you can use this simple app: > https://github.com/dimula73/hdrtest > > > [1] - https://codereview.qt-project.org/#/c/252185/1 > > On Mon, Nov 26, 2018 at 6:14 PM Boudewijn Rempt wrote: > > On maandag 26 november 2018 13:14:12 CET Allan Sandfeld Jensen wrote: > > > It depends on what you want. Using Display P3 for instance is just > > > wide-gamut not HDR. You can get that with just the new color-space > > > > support > > > > > and higher non-extended color precision. That is the primary motivation > > > > for > > > > > doing that first as wide-gamut monitors are already on the market and in > > > the hands of many (high-) end-users. Where HDR is still mostly > > > non-standardized on PC monitors. > > > > We're specifically working on support for the VESA DisplayHDR standard: > > https://displayhdr.org/ . I'm testing with a ASUS ROG Swift PG27UQ > > monitor. > > > > > The use of extended RGB, as scRGB is also known, is very useful behind > > > > the > > > > > scenes in any case, as using that you can map to and from any > > > color-space > > > without clamping, so we can keep something that is internally like sRGB, > > > while still supporting wide-gamut by later taking the extended-sRGB and > > > turning it back into a non-extended wide-gamut image. This makes it > > > possibly to put the clamping and final color-space conversion in the > > > QPA, > > > while keeping the rest generic. So I would still support at least > > > linear-scRGB (aka extended-linear- sRGB), even if only as an > > > intermediate > > > format. > > > > > > It is arguably a strange non-sensical format with many impossible > > > colors, > > > but it is also very useful. > > > > > > Also doesn't BT.2020 also require extended color-values above (1.0, 1,0, > > > 1.0) in most encodings? > > > > Well... We're not doing image manipulation using Qt classes. We simply > > have a > > buffer, handle that using opencolorio (which has suddenly seen a huge > > amount > > of development) to generate another buffer that gets stuffed into f16 > > textures > > and displayed. The amazing thing is that we've actually massaged Angle and > > Qt > > into making that possible using QOpenGLWidget. > > > > The result is a set of patches that we want to clean up and upstream :-) > > > > -- > > https://www.krita.org___ > > Development mailing list > > developm...@lists.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
> Sent: Tuesday, February 12, 2019 at 9:54 AM > From: "Volker Hilsheimer" > To: "Jason H" > Cc: "Vitaly Fanaskov" , "development@qt-project.org" > > Subject: Re: [Development] New API design for file system operations > > > > > On 11 Feb 2019, at 19:16, Jason H wrote: > > > > > >> 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. > > But that’s a usecase for a “move-stuff-to-the-trash” function, right? As in > “remove those files, but do not delete them permanently”. > > The user would expect to be able to see what’s in the trash, and to restore > stuff from there, using the standard desktop trash-can metaphore, not some > application specific shenanigans. > > You would want the application perhaps to be aware of the user restoring data > from the trash, ie adding the files back into the workspace, or the photos > back into the library. In that sense, "restoring from trash" is just the same > as “restoring from backup” or “downloading from the internet”, I suppose. If there is a restore function, I would only expect it to exist as an "undo" operation. Like if a cat walked on the keyboard pressing the delete key. Although it probably doesn't really matter to Qt. The move to trash and undo pair of operations should both be supported. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New API design for file system operations
On 12 Feb 2019, at 10:37, Eike Ziller mailto:eike.zil...@qt.io>> wrote: On Feb 12, 2019, at 09:54, Volker Hilsheimer mailto:volker.hilshei...@qt.io>> wrote: On 11 Feb 2019, at 19:16, Jason H mailto:jh...@gmx.com>> wrote: 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. But that’s a usecase for a “move-stuff-to-the-trash” function, right? As in “remove those files, but do not delete them permanently”. The user would expect to be able to see what’s in the trash, and to restore stuff from there, using the standard desktop trash-can metaphore, not some application specific shenanigans. You would want the application perhaps to be aware of the user restoring data from the trash, ie adding the files back into the workspace, or the photos back into the library. In that sense, "restoring from trash" is just the same as “restoring from backup” or “downloading from the internet”, I suppose. The context of the top statement here seems to have gotten lost, but “restoring data from the trash” would in the best case be part of the undo stack of the application which you used to trash it, so I’d argue that “restoring data from the trash” is an operation that an application would like to have access to (at least for the file that it trashed before). Context being whether a “moveToTrash” API without a comprehensive trash-can-management API (which gives access to the contents, the ability to empty the trash, and the ability to restore arbitrary content from the trash-can) is a good idea. The moveToTrash API as suggested in https://bugreports.qt.io/browse/QTBUG-47703 returns the location of the file in the trash-can after the move, so the application can store that information and give the option to restore those files/directories that were trashed through the application. Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QDialog vs QPushButton and it's autoDefault default
> On 11 Feb 2019, at 22:47, Bernhard Lindner > wrote: > > 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? Hey Bernhard, The default button gets pressed when the user presses Enter in a dialog, unless an autoDefault button has focus, in which case that button will be pressed. That’s what the user would expect. So, that your button is pressed when focus is in a QLineEdit would suggest that your clear button is the next autoDefault button in the focus chain (as per the documented behavior, and that there is no default button. Note that when using QDialogButtonBox, you only get a default button if one of the buttons in the box has the “Accept” role - otherwise you have to make one of the buttons the default button explicitly. So to your questions: 1) the behavior you are seeing seems to be as it should be, but you might have to set a default button for autoDefault heuristics not to take over completely and cause confusion. 2) Opt-out would make it more work to have the kind of UI the user expects (focused button is pressed on Enter). 3) QDialogButtonBox isn’t visible to the user, so a button behavior differnelty in a dialog just because it’s laid out in code with the help of QDialogButtonBox seems somewhat arbitrary. 4) Default values of object properties being context dependent is not that unusual Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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.
Wow, first of all thanks for taking the time for this awesome feedback.
I guess the QFuture/QFutureWatcher design was driven by Qt's needs as I
developed QDeferred for my very own needs. I suppose one just have to use
the tool that best fits the problem.
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)
Agree. There are use cases where QFutureWatcher is better.
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.
Yes is possible to have multiple subscribers, thank you for pointing at it,
I forgot to mention it explicitly in the readme. It is done as follows:
QDeferred defer = myMethod()
>
> .done([](int val) {
>
> })
>
> .fail([](int val) {
>
>
>> });
>
>
>> // we can pass "defer" around since is a explicitly shared object
>
> // ...
>
>
>> // subscribe elsewhere
>
> defer
>
> .done([](int val) {
>
>
>> })
>
> .fail([](int val) {
>
>
>> });
>
>
And if the QDeferred was already resolved/rejected when a new subscription
is done, then the callback is called inmediatly (depending on the
connection-type, more on this later). I will add this to the document.
I didn’t see cancel functionality in your work, do you have thoughts on
this?
I didn't think of this, haven't had the need but it is a great idea! I
think it should not be too hard to implement. Maybe an API method called
"cancel" and a callback called "cancelled" so we know when the process has
actually been cancelled,
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.
Yes and no, actually this was a hard decision for me. One main
differentator with QDeferred is that there are N result types, so we could
get around the issue as follows:
QDeferred defer = myMethod()
>
> .progress([](QByteArray result, int progress, QString message) {
>
> Q_UNUSED(result);
>
> qDebug() << "Progress" << progress << "% , details :" << message;
>
> })
>
> .done([](QByteArray result, int progress, QString message) {
>
> Q_UNUSED(progress, message);
>
> // do something with the QByteArray results
>
> });
>
>
The fact that you have N result types does not mean you have to use all of
them in every callback. You could use some of them for progress info and
some others for results. I know this might come as "akward", but what
actually constitute a "progress"? At some point I though of adding a
specialized or API for the progress but decided not to
because it would be limiting. E.g. one of my use cases was to bring large
chunks of historic data from a server, and the "progress" for that use case
was partial data blocks which I could inmediatly display in a chart as they
arrived, so one of my return types was a reference to that partial data
block which I only used in the progress callback. Maybe there is a better
way to achieve this, but I couldn't find one that met all my needs.
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.
This sounds like a good idea, but makes me wonder; isn't it the
reponsibility of the user to create sensible reporting? I mean, I could
drown my CPU with a for-loop, is it the fault of the for-loop or my fault
for using it incorrectly? Nevertheless it is indeed always a good idea to
program in a defensive way. Can I ask how does Qtconcurrent implements this
protection?
One nice thing about QFuture/QFutureInterface is that one doesn’t actually
need to create an _actual_ async task to use the same
Re: [Development] New API design for file system operations
> On Feb 12, 2019, at 09:54, Volker Hilsheimer wrote: > > > >> On 11 Feb 2019, at 19:16, Jason H wrote: >> >> >>> 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. > > But that’s a usecase for a “move-stuff-to-the-trash” function, right? As in > “remove those files, but do not delete them permanently”. > > The user would expect to be able to see what’s in the trash, and to restore > stuff from there, using the standard desktop trash-can metaphore, not some > application specific shenanigans. > > You would want the application perhaps to be aware of the user restoring data > from the trash, ie adding the files back into the workspace, or the photos > back into the library. In that sense, "restoring from trash" is just the same > as “restoring from backup” or “downloading from the internet”, I suppose. The context of the top statement here seems to have gotten lost, but “restoring data from the trash” would in the best case be part of the undo stack of the application which you used to trash it, so I’d argue that “restoring data from the trash” is an operation that an application would like to have access to (at least for the file that it trashed before). -- 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
Re: [Development] New API design for file system operations
> On 11 Feb 2019, at 19:16, Jason H wrote: > > >> 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. But that’s a usecase for a “move-stuff-to-the-trash” function, right? As in “remove those files, but do not delete them permanently”. The user would expect to be able to see what’s in the trash, and to restore stuff from there, using the standard desktop trash-can metaphore, not some application specific shenanigans. You would want the application perhaps to be aware of the user restoring data from the trash, ie adding the files back into the workspace, or the photos back into the library. In that sense, "restoring from trash" is just the same as “restoring from backup” or “downloading from the internet”, I suppose. Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
