On 05/17/2010 12:01 PM, Tomeu Vizoso wrote: > On Thu, May 6, 2010 at 07:14, Aleksey Lim<alsr...@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 [0]. >>> >>> This feature was requested in [1] and sponsored by Activity Central [2]. >>> >>> 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 >>> Proposal. >>> >>> 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 [3]. 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.
I hope I understand this right, please state so if not. As it is perfectly ok to develop new solutions, a maintainer, should well maintain existing code. We have <= 0.84 shipped to 1 million kids, and the Journal as it exists is a very important part of the Sugar experience. Please think about the position you have in. Regards, Simon _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel