[Sugar-devel] journal maintenance (was Re: [RFC PATCH v0 0/8] Journal sorting by file size and creation time.)
tomeu at tomeuvizoso.net
Mon May 17 06:01:53 EDT 2010
On Thu, May 6, 2010 at 07:14, Aleksey Lim <alsroot at member.fsf.org> wrote:
> On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote:
>> This patchset implements sorting in the Journal UI as described in .
>> This feature was requested in  and sponsored by Activity Central .
>> Sorting by filesize is vital in the field where users need to free up disk
>> space. Currently, the only way to find candidates for deletion is to access
>> the expanded view of each entry, one by one. This can be a very time consuming
>> process and often leads to indiscriminate deletion and thus potential loss of
>> valuable data. This is bad.
>> Sorting by creation time (ctime) is also implemented as described in the Design
>> This implementation currently lacks two aspects which I hope will be sorted out
>> in the review process:
>> 1- The proposal does not include a specification for changing the order of the
>> sort. This patch assumes an ascending order.
>> 2- There are no icons for the sorting criteria. Or at least I couldn't find the
>> ones presented in the proposal. I'm sure someone from the design team could
>> vectorize the ones there.
>> v0: Initial submission to sugar-devel
> As current datastore and journal maintainer, some points:
> I'm still not sure will ml path proposal scheme work on not, it removes
> some bugs.sl.o issues but adds new e.g. it is pretty hard to collaborate
> (in my mind) via ml history, in case of bugs.sl.o, someone can just
> share http link to complicated query. Other thing is that on bugs.sl.o
> it is easy to query tickets by keywords for example.
> And since having patches both on bugs.sl.o and ml is pretty useless and
> there is no regular way to attach "0.90 targeted" keyword to ml posts,
> please create tickets on bugs.sl.o.
> In case of journal, my strong thinking is that Journal shouldn't be only
> one for all purposes and it shouldn't be only in glucose as part of
> sugar core. I initiated journal library . The major idea is that
> anyone can create his own journal activity and glucose can provide
> common/simple/default one.
> So, all my resources I spend to journal library (and related projects)
> not to journal code in glucose.
Btw, it's a bit awkward that the official journal maintainer says it
won't dedicate time to it any more.
Should we consider the existing journal officially unmaintained and
look for candidates?
> If you share this thinking, please come
> Having covered all the above, I thing only datastore patch is requested.
>  http://wiki.sugarlabs.org/go/Activity_Team/Services/Journal
>>  http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Extended_list_view_palette
>>  http://bugs.sugarlabs.org/ticket/1915
>>  http://activitycentral.org
>> Andrés Ambrois (8):
>> Journal: Retrieve ctime and filesize from the datastore.
>> Add ctime and filesize columns to the journal list model.
>> Add add_separator method for convenience.
>> Add a ListViewButton to the journal search toolbar.
>> Rename the date column to 'sort_column'
>> Add sort_by method to the journal list view.
>> Call sort_by in the list view when sorting is selected in the
>> Expandedentry: Try to use the filesize property.
>> src/jarabe/journal/expandedentry.py | 5 +-
>> src/jarabe/journal/journalactivity.py | 5 ++
>> src/jarabe/journal/journaltoolbox.py | 75 ++++++++++++++++++++++++++++++++-
>> src/jarabe/journal/listmodel.py | 22 +++++++---
>> src/jarabe/journal/listview.py | 34 ++++++++++-----
>> src/jarabe/journal/model.py | 6 +-
>> 6 files changed, 124 insertions(+), 23 deletions(-)
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel