On Mon, Aug 23, 2010 at 18:08, Andrés Ambrois <andresambr...@gmail.com> wrote: > On Monday, August 23, 2010 04:25:48 am Tomeu Vizoso wrote: >> On Sat, Aug 21, 2010 at 01:24, Aleksey Lim <alsr...@member.fsf.org> wrote: >> > Hi all, >> > >> > Implement sorting in the Journal UI. Also adds support for the two new >> > properties (filesize and ctime). >> > >> > Feature page: >> > http://wiki.sugarlabs.org/go/Features/Journal_Sort >> > >> > Implementations: >> > http://git.sugarlabs.org/projects/sugar-datastore/repos/journal_sort >> > http://git.sugarlabs.org/projects/sugar/repos/journal_sort >> >> Some questions: >> >> - what with hard links? Aren't users going to expect that if they >> delete an entry of 50MB that their available space will be increased >> by 50MB? > > One way or the other, we are going to leak the abstraction that different > journal entries consume disk space independently; be it by the behavior you > describe, or providing some sort of visual hints. I don't think there's much > we can do except making it clear that file size is just a hint these days > (think filesystem compression).
Sounds good. >> - creation time will be always displayed as '%Y-%m-%dT%H:%M:%S' ? What >> about those countries where they expect the fields being ordered in a >> different way? (may be good to format the string in listview.py >> instead of in listmodel.py, so we keep UI decisions out from the >> model). > > I agree with that separation of concerns. In fact it was initially that way, > but the format is required by activities such as Etoys, that break unless we > use it. Other activities may also be depending on it, as it is documented in > [0]. Fair enough. >> - if we are not interested in sorting by title, we should remove that >> field from the index, because makes the index bigger and also slows >> queries down a bit. > > As I've learned from this work, adding/removing DS properties should be done > with care, as everything can break in a gazillion ways. In any case, that > belongs to a different patchset. But you see that if we let patches come without asking the submitter to counter any regressions in performance-critical areas then we'll get inevitably slower and slower? >> - seems like this feature is still in dicussion in >> http://bugs.sugarlabs.org/ticket/1915 so I don't think it makes sense >> to accept it for inclusion in 0.90 at this stage. Also would be good >> to have the feature first accepted in the release set before >> eventually merging it. > > It would be a shame for it to miss the boat, but I think that this should get > plenty of testing as it may cause data loss for users. In any case, I think we need to decide first of all what we want to land with respect to the issues that Gary found. Regards, Tomeu >> Regards, >> >> Tomeu >> >> > -- >> > Aleksey > > [0] http://wiki.sugarlabs.org/go/Development_Team/Low- > level_Activity_API#Meta_Data > -- > -Andrés > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel