Re: [Development] All deprecation warnings are P1 for 5.13.0

[Christian Ehrlicher]

Am 09.02.2019 um 07:34 schrieb Giuseppe D'Angelo via Development:

Hi,

Il 09/02/19 02:27, Thiago Macieira ha scritto:

Commit 7847e6bc02552fa7fc7f518e5cb3336f667b5a6d in qtbase madee the
QT_DEPRECATED and QT_DEPRECATED_X warnings on by default in Qt 
builds. That

means we started seeing lots of warnings that weren't there in 5.12.


Agree with the rest of the email. From a purely technical point of
view, however, I'm wondering why we didn't see those warnings before? 
Qt was already built with warnings enabled AFAICS? For instance:
It was only enabled for src, not for examples and tests so I did not saw 
the warnings before your commit I would guess. So even functions which 
were already marked deprecated for a long time did not trigger warnings. 
Fixing all the examples and tests before 5.13beta is ... challenging. 
And doing this for anything other than qtbase is not possible for me 
during my limited time.



Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] All deprecation warnings are P1 for 5.13.0

[Giuseppe D'Angelo via Development]

Hi,

Il 09/02/19 02:27, Thiago Macieira ha scritto:

Commit 7847e6bc02552fa7fc7f518e5cb3336f667b5a6d in qtbase madee the
QT_DEPRECATED and QT_DEPRECATED_X warnings on by default in Qt builds. That
means we started seeing lots of warnings that weren't there in 5.12.


Agree with the rest of the email. From a purely technical point of
view, however, I'm wondering why we didn't see those warnings before? Qt 
was already built with warnings enabled AFAICS? For instance:



https://code.qt.io/cgit/qt/qtbase.git/tree/mkspecs/features/qt_module.prf?h=5.13#n310


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@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.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] All deprecation warnings are P1 for 5.13.0

[Thiago Macieira]

Commit 7847e6bc02552fa7fc7f518e5cb3336f667b5a6d in qtbase madee the 
QT_DEPRECATED and QT_DEPRECATED_X warnings on by default in Qt builds. That 
means we started seeing lots of warnings that weren't there in 5.12.

ALL such warnings must be fixed by 5.13.0 release. Please treat them as P1 (or 
P½ because flooding my output while building makes finding legitimate warnings 
and errors more difficult).

I've begun reporting in Gerrit on the commits that added the deprecation, if 
that commit was recent enough. But there's new code using  years 
after those functions were deprecated...

By beta, those that aren't fixed will get P1 bug reports in JIRA.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New API design for file system operations

[Volker Hilsheimer]

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. IIRC these classes have changed very 
little since Qt 1.

Unifying QFile and QDir around a common baseclass seems difficult. QFile is a 
QObject via QFileDevice and QIODevice; QDir is a copyable value type. Since you 
can point a QDir to a file, it’s perhaps closer to a value representing a file 
system entry. Making them both inherit an “operations” interface just to be 
able to remove either a file or a directory in the same way seems cluttery, esp 
given the ambitions for such an “operations” interface I’m lining out above 
(get progress updates, cancelable, transactions, batch jobs, run in a thread 
etc).

Adding such an interface would clutter those APIs, and require duplication in a 
lot of places. 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.


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.

Happy to be convinced otherwise.


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

[Marco Bubke]

+2

On February 8, 2019 11:12:25 Christian Kandeler  
wrote:

> On Thu, 7 Feb 2019 16:03:30 +
> Volker Hilsheimer  wrote:
>
>> Thoughts, ideas, and pointers to other frameworks that you believe provide a 
>> good API are welcome here in this email thread before moving to a dedicated 
>> JIRA ticket.
>
> My personal pet peeve: Please, let's never again use the term "file name" 
> when we actually mean a file path.
>
>
> Christian
> ___
> 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

[Shawn Rutledge]

> On 8 Feb 2019, at 11:10, Christian Kandeler  wrote:
> 
> On Thu, 7 Feb 2019 16:03:30 +
> Volker Hilsheimer  wrote:
> 
>> Thoughts, ideas, and pointers to other frameworks that you believe provide a 
>> good API are welcome here in this email thread before moving to a dedicated 
>> JIRA ticket. 
> 
> My personal pet peeve: Please, let's never again use the term "file name" 
> when we actually mean a file path.

+1: maybe it’s a good time to fix up the badly named functions at least (we 
could even start adding new and deprecating old ones soon, not wait for Qt 6).

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New API design for file system operations

[Daniel Engelke]

+1 when I first started, that threw me off as well.

Daniel



 From:   Christian Kandeler  
 To:   "development@qt-project.org"  
 Sent:   2/8/2019 11:10 AM 
 Subject:   Re: [Development] New API design for file system operations 

On Thu, 7 Feb 2019 16:03:30 +
Volker Hilsheimer  wrote:

> Thoughts, ideas, and pointers to other frameworks that you believe provide a 
> good API are welcome here in this email thread before moving to a dedicated 
> JIRA ticket. 

My personal pet peeve: Please, let's never again use the term "file name" when 
we actually mean a file path.


Christian
___
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

[Tor Arne Vestbø]

> On 8 Feb 2019, at 10:43, Vitaly Fanaskov  wrote:
> 
> Hi,
> 
> I've read QTBUG-47703 very carefully and I think that adding some file 
> managers is overkill in this particular case.

I agree, QFile and QDir are natural places to look for such APIs.

Tor Arne 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New API design for file system operations

[Christian Kandeler]

On Thu, 7 Feb 2019 16:03:30 +
Volker Hilsheimer  wrote:

> Thoughts, ideas, and pointers to other frameworks that you believe provide a 
> good API are welcome here in this email thread before moving to a dedicated 
> JIRA ticket. 

My personal pet peeve: Please, let's never again use the term "file name" when 
we actually mean a file path.


Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] HEADS-UP: Qt 5.13 API review

[Jani Heikkinen]

Hi all,

Just kindly reminder: API review for Qt 5.13 is ongoing. It seems there isn't 
that much activity yet...

br,
Jani

From: Edward Welbourne
Sent: Monday, February 4, 2019 1:38 PM
To: Jani Heikkinen; development@qt-project.org
Cc: releas...@qt-project.org
Subject: Re: HEADS-UP: Qt 5.13 Feature Freeze is in effect now

Jani Heikkinen (1 February 2019 13:53) wrote:
> Feature freeze for Qt 5.13 is now in effect and branching from 'dev' to 
> '5.13' is complete.

and that means it's time to review changes to all our APIs, please see
https://codereview.qt-project.org/#/q/status:open+branch:5.13+topic:api-review,n,z
and check up on the modules you know well or care about.

If you have objections to changes, file bugs against relevant components
and mark task QTBUG-73484 as blocked by them.  (If you're very quick,
you might get to the reviews before I correct their Task-number footers
to mention this one, so don't use PS1's task numbers.)

If there are new APIs in there, this is a good moment to remember:

> If not already done please update Qt 5.13 new features page:
> https://wiki.qt.io/New_Features_in_Qt_5.13

Remember, these are P0 blockers,

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New API design for file system operations

[Vitaly Fanaskov]

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.

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.

The relevant disussion starts here:

https://bugreports.qt.io/browse/QTBUG-47703?focusedCommentId=445952=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-445952

and I’d like to have a few more eyeballs on that (that ticket is already being 
watched by 30+ people, so I do anticipate some interest).

I’d like to strike the balance between an API that’s easy to use, can deal with 
both atomic (delete a file) and complex operations (such as copying a file, or 
moving files between file systems), but that at the same time allows Qt users 
to control how operations are performed (batching jobs, executing 
synchronously, or asynchronously with progress updates, perhaps the ability to 
cancel, rate limit in case of network traffic being involved etc).

Thoughts, ideas, and pointers to other frameworks that you believe provide a 
good API are welcome here in this email thread before moving to a dedicated 
JIRA ticket. Thiago mentioned the KIO framework as a source for inspiration; I 
had to deal with IFileManager when implementing moving to trash on Windows.

Would be great if we can come up with something that allows us to include the 
move-to-trash functionality in Qt 5.14.


Cheers,
Volker



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development