---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118128/
---
(Updated June 2, 2014, 11:44 a.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118128/#review58955
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118128/#review58849
---
Ship it!
Ship It!
- David Faure
On May 29, 2014, 5 p.m.,
On May 14, 2014, 2:24 p.m., David Faure wrote:
It is correct that this is about a string representation of the filesize,
to displaying in a column of the model.
For machine processing one can use KFileItem::size() after getting the
KFileItem out of the KDirModel.
However, do we
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118128/
---
(Updated May 29, 2014, 7 p.m.)
Review request for KDE Frameworks and
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118128/#review58752
---
hehehe, that's quite a change.
This will keep sorting happy.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118128/
---
Review request for KDE Frameworks and David Faure.
Repository: kio
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118128/#review57921
---
Ehh..
Does this mean that there is no way to get the actual
On May 14, 2014, 4:13 p.m., Mark Gaiser wrote:
Ehh..
Does this mean that there is no way to get the actual byte size anymore?
In that case i think it would be better to introduce a new role:
HumanReadableSize which does what your patch is doing now.
Note: i really think that
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118128/#review57923
---
It is correct that this is about a string representation of
On May 14, 2014, 2:13 p.m., Mark Gaiser wrote:
Ehh..
Does this mean that there is no way to get the actual byte size anymore?
In that case i think it would be better to introduce a new role:
HumanReadableSize which does what your patch is doing now.
Note: i really think that
On May 14, 2014, 2:24 p.m., David Faure wrote:
It is correct that this is about a string representation of the filesize,
to displaying in a column of the model.
For machine processing one can use KFileItem::size() after getting the
KFileItem out of the KDirModel.
However, do we
On May 14, 2014, 4:24 p.m., David Faure wrote:
It is correct that this is about a string representation of the filesize,
to displaying in a column of the model.
For machine processing one can use KFileItem::size() after getting the
KFileItem out of the KDirModel.
However, do we
On May 14, 2014, 2:24 p.m., David Faure wrote:
It is correct that this is about a string representation of the filesize,
to displaying in a column of the model.
For machine processing one can use KFileItem::size() after getting the
KFileItem out of the KDirModel.
However, do we
On May 14, 2014, 2:24 p.m., David Faure wrote:
It is correct that this is about a string representation of the filesize,
to displaying in a column of the model.
For machine processing one can use KFileItem::size() after getting the
KFileItem out of the KDirModel.
However, do we
On May 14, 2014, 4:24 p.m., David Faure wrote:
It is correct that this is about a string representation of the filesize,
to displaying in a column of the model.
For machine processing one can use KFileItem::size() after getting the
KFileItem out of the KDirModel.
However, do we
16 matches
Mail list logo
