Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
I'm unqualified to review your code, but I've included both your patch series both in my sugar-jhbuild environment and in my Sugar 0.88 packages for Fedora 11. El Sat, 01-05-2010 a las 16:33 -0300, Andrés Ambrois escribió: 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 toolbar. Expandedentry: Try to use the filesize property. Tested-by: Bernie Innocenti ber...@codewiz.org Andrés Ambrois (2): Add ctime and timestamp properties to the index. Add migration from DS v0 code for the new properties. Tested-by: Bernie Innocenti ber...@codewiz.org Problems: * size display does not work on removable devices: all files are shown as empty. * I forgot to include the patch to increment CURRENT_LAYOUT_VERSION, which caused old journal entries to report an empty size, but no other problems. * The icon for the new toolbar button is missing -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
On Thu, May 06, 2010 at 05:14:44AM +, Aleksey Lim 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, The man page for git format-patch from git 1.7.1 shows options like --subject-prefix --add-header which can be used to tag patches for branches. These options can also be configured in .gitconfig or .git/config like so: [format] headers = Organization: git-foo\n subjectprefix = CHANGE (@Martin, Bernie: how would one configure branch-specific format settings?) Finally, Trac-like querying capabilities can be easily regained via email search tools like notmuch. Regards, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
On Thu, May 06, 2010 at 05:13:38AM -0300, Andrés Ambrois wrote: On Thursday 06 May 2010 02:14:44 am you wrote: On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote: snip 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. Hi Aleksey. Thanks for taking the time to look at this. While I personally don't think it's that hard to collaborate on the ml, I believe this discussion belongs in the Code Review process changes thread [0]. Either way, the bug I referred to (#1915) contains the previous discussion and links to both patchsets. It is also tagged as r?, though no one has taken a look at it yet. I should say that the fact that you commented on this thread before you did so on the ticket is evidence that reviewing patches here managed, at worst, to grab the right person's attention, and at best will work the same for others. But I digress. I think your opinion is important and should be part of that thread. 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. If you share this thinking, please come aboard. I'm not convinced, but I could be. While I think opening up the API might encourage activity developers to produce their own (potentially better) journal UI's, I feel it is a mistake to stop improving the canonical interface for accessing the user's data: it is orthogonal; we can work on improving the current UI _and_ provide the tools you mention. Well, I was talking only from personal POV, having: * ugly gtk.TreeView usage in journal (lack of lazy model in gtk.TreeView) * need to integrate thumbs view For my own, I decided to concentrate all attention only on new journal library because fixing both mentioned code in step-by-step (when step it is glucose release) is pretty useless. New journal library inherited some model level code and has completely different UI part - field-widget based design and using HomogenTable list widget instead of gtk.TreeView. More over, I decided to create this library using only Polyol (w/o sugar-toolkit at all) to conform another my strong thinking [4]. So, all this work can't be done within glucose. [4] http://wiki.sugarlabs.org/go/Documentation_Team/Services/Scalable_development_model If you think Journal development should be halted until it is moved out of glucose, we should get working on that; deployments need this feature. To be honest, I didn't think about it at all. I have only one simple idea, create more functional journal and give a chance to users to use it on 0.82+ sugars. With journal only in glucose, only 0.90 users will get features like thumbs view, with activity based scheme (since I'm planing to support 0.82+ in journal library) all users (keeping in mind that current stable OLPC release is 0.82, next stable will be 0.84) all of XO users will have a chance to use new journal like activities. Thus, in my mind, library journal is more important. On the other hand, the Journal was once an activity but was integrated into the shell in 0.84 (see commit f0ff3b) for performance and maintainability reasons, have any of those priorities changed in your mind? In performance case, new library use the same model scheme (except minor improvements) thus performance will be the same. About other aspects of journal integration like security issues, my first intention was not create full functional replacement of current journal, only that could be done w/o close core integration. Creating full functional replacement will require shell dbus API improvements, I was planing to create ready-to-use first journal library based activity (Library-2) and only than propose appropriate shell dbus API features. I've taken a look at some of the components of your Polyol project and I'm impressed by the quality and quantity of your work, congrats!. Having covered all the above, I thing only datastore patch is requested. You mean only the DS patch will be accepted? Sorry, I meant s/requested/required/, and of course I was talking from current journal maintainer POV. If there is someone
Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
On Fri, May 7, 2010 at 11:05, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, May 06, 2010 at 05:13:38AM -0300, Andrés Ambrois wrote: On Thursday 06 May 2010 02:14:44 am you wrote: On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote: snip 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. Hi Aleksey. Thanks for taking the time to look at this. While I personally don't think it's that hard to collaborate on the ml, I believe this discussion belongs in the Code Review process changes thread [0]. Either way, the bug I referred to (#1915) contains the previous discussion and links to both patchsets. It is also tagged as r?, though no one has taken a look at it yet. I should say that the fact that you commented on this thread before you did so on the ticket is evidence that reviewing patches here managed, at worst, to grab the right person's attention, and at best will work the same for others. But I digress. I think your opinion is important and should be part of that thread. 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. If you share this thinking, please come aboard. I'm not convinced, but I could be. While I think opening up the API might encourage activity developers to produce their own (potentially better) journal UI's, I feel it is a mistake to stop improving the canonical interface for accessing the user's data: it is orthogonal; we can work on improving the current UI _and_ provide the tools you mention. Well, I was talking only from personal POV, having: * ugly gtk.TreeView usage in journal (lack of lazy model in gtk.TreeView) * need to integrate thumbs view For my own, I decided to concentrate all attention only on new journal library because fixing both mentioned code in step-by-step (when step it is glucose release) is pretty useless. New journal library inherited some model level code and has completely different UI part - field-widget based design and using HomogenTable list widget instead of gtk.TreeView. More over, I decided to create this library using only Polyol (w/o sugar-toolkit at all) to conform another my strong thinking [4]. So, all this work can't be done within glucose. [4] http://wiki.sugarlabs.org/go/Documentation_Team/Services/Scalable_development_model If you think Journal development should be halted until it is moved out of glucose, we should get working on that; deployments need this feature. To be honest, I didn't think about it at all. I have only one simple idea, create more functional journal and give a chance to users to use it on 0.82+ sugars. With journal only in glucose, only 0.90 users will get features like thumbs view, with activity based scheme (since I'm planing to support 0.82+ in journal library) all users (keeping in mind that current stable OLPC release is 0.82, next stable will be 0.84) all of XO users will have a chance to use new journal like activities. Thus, in my mind, library journal is more important. I'm worried about how this could affect deployments negatively, but as we don't have a forum for developers to discuss these subjects with them... IMHO, you as a maintainer shouldn't take such a decision without making at least some efforts to make sure you aren't jeopardizing the ability of downstreams to pick up future versions of Sugar. I know it's very hard right now for developers like you to get that feedback, but unfortunately there doesn't seem to be enough interest to create a deployment team where these questions could be brought... Regards, Tomeu On the other hand, the Journal was once an activity but was integrated into the shell in 0.84 (see commit f0ff3b) for performance and maintainability reasons, have any of those priorities changed in your mind? In performance case, new library use the same model scheme (except minor improvements) thus performance will be the same. About other aspects of journal integration like security issues, my first intention was not create full functional replacement of current journal, only that could be done w/o
Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
On Fri, May 07, 2010 at 11:15:12AM +0200, Tomeu Vizoso wrote: On Fri, May 7, 2010 at 11:05, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, May 06, 2010 at 05:13:38AM -0300, Andrés Ambrois wrote: On Thursday 06 May 2010 02:14:44 am you wrote: On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote: If you think Journal development should be halted until it is moved out of glucose, we should get working on that; deployments need this feature. To be honest, I didn't think about it at all. I have only one simple idea, create more functional journal and give a chance to users to use it on 0.82+ sugars. With journal only in glucose, only 0.90 users will get features like thumbs view, with activity based scheme (since I'm planing to support 0.82+ in journal library) all users (keeping in mind that current stable OLPC release is 0.82, next stable will be 0.84) all of XO users will have a chance to use new journal like activities. Thus, in my mind, library journal is more important. I'm worried about how this could affect deployments negatively, but as we don't have a forum for developers to discuss these subjects with them... Well, at the end polyol/libjournal for me are experimental projects that could be somehow part of glucose, but they couldn't be as well because they are designed to be glucose agnostic. IMHO, you as a maintainer shouldn't take such a decision without making at least some efforts to make sure you aren't jeopardizing the ability of downstreams to pick up future versions of Sugar. I know it's very hard right now for developers like you to get that feedback, but unfortunately there doesn't seem to be enough interest to create a deployment team where these questions could be brought... Well, at the end we talking about two not-so-similar schemes: developer - deployment/QA/releases/etc - user and developer/doer - user/doer In my mind, sugar by nature is 2nd, but 1st scheme is also important (OLPC, XO, SOAS). But strive for only 1st scheme, imho, is pretty wrong way. Everything I'm doing is from a man who are from 2nd scheme: * more decentralized deployment (0sugar) * more decentralized development (polyol) * more decentralized collaboration (Activity_Library activity [5] [6]) I'm sure 2nd scheme is not less important (at least), and more appropriate to community-driven projects like sugar (not sugar like an OS on XO). [5] http://wiki.sugarlabs.org/go/Activities/Activity_Library [6] http://wiki.sugarlabs.org/go/Collab_mockup -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
On Fri, May 7, 2010 at 11:56, Aleksey Lim alsr...@member.fsf.org wrote: On Fri, May 07, 2010 at 11:15:12AM +0200, Tomeu Vizoso wrote: On Fri, May 7, 2010 at 11:05, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, May 06, 2010 at 05:13:38AM -0300, Andrés Ambrois wrote: On Thursday 06 May 2010 02:14:44 am you wrote: On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote: If you think Journal development should be halted until it is moved out of glucose, we should get working on that; deployments need this feature. To be honest, I didn't think about it at all. I have only one simple idea, create more functional journal and give a chance to users to use it on 0.82+ sugars. With journal only in glucose, only 0.90 users will get features like thumbs view, with activity based scheme (since I'm planing to support 0.82+ in journal library) all users (keeping in mind that current stable OLPC release is 0.82, next stable will be 0.84) all of XO users will have a chance to use new journal like activities. Thus, in my mind, library journal is more important. I'm worried about how this could affect deployments negatively, but as we don't have a forum for developers to discuss these subjects with them... Well, at the end polyol/libjournal for me are experimental projects that could be somehow part of glucose, but they couldn't be as well because they are designed to be glucose agnostic. IMHO, you as a maintainer shouldn't take such a decision without making at least some efforts to make sure you aren't jeopardizing the ability of downstreams to pick up future versions of Sugar. I know it's very hard right now for developers like you to get that feedback, but unfortunately there doesn't seem to be enough interest to create a deployment team where these questions could be brought... Well, at the end we talking about two not-so-similar schemes: developer - deployment/QA/releases/etc - user and developer/doer - user/doer In my mind, sugar by nature is 2nd, but 1st scheme is also important (OLPC, XO, SOAS). But strive for only 1st scheme, imho, is pretty wrong way. Everything I'm doing is from a man who are from 2nd scheme: * more decentralized deployment (0sugar) * more decentralized development (polyol) * more decentralized collaboration (Activity_Library activity [5] [6]) I'm sure 2nd scheme is not less important (at least), and more appropriate to community-driven projects like sugar (not sugar like an OS on XO). Like it or not, Sugar gets used because someone deploys it, and in 99.9% of the cases it's not the final user who deploys it. If we pretend otherwise, Sugar won't reach users in an optimal way and we are failing to aim for our stated goals. I don't think it's entirely your fault, because deployers are trusting that SLs' maintainers will guess what they need without them having to get involved, which is the root cause of this problem. Regards, Tomeu [5] http://wiki.sugarlabs.org/go/Activities/Activity_Library [6] http://wiki.sugarlabs.org/go/Collab_mockup -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
On Fri, May 07, 2010 at 12:04:38PM +0200, Tomeu Vizoso wrote: On Fri, May 7, 2010 at 11:56, Aleksey Lim alsr...@member.fsf.org wrote: On Fri, May 07, 2010 at 11:15:12AM +0200, Tomeu Vizoso wrote: On Fri, May 7, 2010 at 11:05, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, May 06, 2010 at 05:13:38AM -0300, Andrés Ambrois wrote: On Thursday 06 May 2010 02:14:44 am you wrote: On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote: If you think Journal development should be halted until it is moved out of glucose, we should get working on that; deployments need this feature. To be honest, I didn't think about it at all. I have only one simple idea, create more functional journal and give a chance to users to use it on 0.82+ sugars. With journal only in glucose, only 0.90 users will get features like thumbs view, with activity based scheme (since I'm planing to support 0.82+ in journal library) all users (keeping in mind that current stable OLPC release is 0.82, next stable will be 0.84) all of XO users will have a chance to use new journal like activities. Thus, in my mind, library journal is more important. I'm worried about how this could affect deployments negatively, but as we don't have a forum for developers to discuss these subjects with them... Well, at the end polyol/libjournal for me are experimental projects that could be somehow part of glucose, but they couldn't be as well because they are designed to be glucose agnostic. IMHO, you as a maintainer shouldn't take such a decision without making at least some efforts to make sure you aren't jeopardizing the ability of downstreams to pick up future versions of Sugar. I know it's very hard right now for developers like you to get that feedback, but unfortunately there doesn't seem to be enough interest to create a deployment team where these questions could be brought... Well, at the end we talking about two not-so-similar schemes: developer - deployment/QA/releases/etc - user and developer/doer - user/doer In my mind, sugar by nature is 2nd, but 1st scheme is also important (OLPC, XO, SOAS). But strive for only 1st scheme, imho, is pretty wrong way. Everything I'm doing is from a man who are from 2nd scheme: * more decentralized deployment (0sugar) * more decentralized development (polyol) * more decentralized collaboration (Activity_Library activity [5] [6]) I'm sure 2nd scheme is not less important (at least), and more appropriate to community-driven projects like sugar (not sugar like an OS on XO). Like it or not, Sugar gets used because someone deploys it, and in 99.9% of the cases it's not the final user who deploys it. If we pretend otherwise, Sugar won't reach users in an optimal way and we are failing to aim for our stated goals. I'm not saying that 1st is less important then 2nd, I meant that 2nd should grow. btw w/ 0install entirely sugar could (will, after implementing Saccharin distro, 0install based sugar) be installed on most of GNU/Linux distrobutions. I don't think it's entirely your fault, because deployers are trusting that SLs' maintainers will guess what they need without them having to get involved, which is the root cause of this problem. Well, maybe my first steps on 2nd way were affected by lack of communication w/ real deployments, but for now, it is my deliberate intention. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
On Fri, May 7, 2010 at 12:18, Aleksey Lim alsr...@member.fsf.org wrote: On Fri, May 07, 2010 at 12:04:38PM +0200, Tomeu Vizoso wrote: On Fri, May 7, 2010 at 11:56, Aleksey Lim alsr...@member.fsf.org wrote: On Fri, May 07, 2010 at 11:15:12AM +0200, Tomeu Vizoso wrote: On Fri, May 7, 2010 at 11:05, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, May 06, 2010 at 05:13:38AM -0300, Andrés Ambrois wrote: On Thursday 06 May 2010 02:14:44 am you wrote: On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote: If you think Journal development should be halted until it is moved out of glucose, we should get working on that; deployments need this feature. To be honest, I didn't think about it at all. I have only one simple idea, create more functional journal and give a chance to users to use it on 0.82+ sugars. With journal only in glucose, only 0.90 users will get features like thumbs view, with activity based scheme (since I'm planing to support 0.82+ in journal library) all users (keeping in mind that current stable OLPC release is 0.82, next stable will be 0.84) all of XO users will have a chance to use new journal like activities. Thus, in my mind, library journal is more important. I'm worried about how this could affect deployments negatively, but as we don't have a forum for developers to discuss these subjects with them... Well, at the end polyol/libjournal for me are experimental projects that could be somehow part of glucose, but they couldn't be as well because they are designed to be glucose agnostic. IMHO, you as a maintainer shouldn't take such a decision without making at least some efforts to make sure you aren't jeopardizing the ability of downstreams to pick up future versions of Sugar. I know it's very hard right now for developers like you to get that feedback, but unfortunately there doesn't seem to be enough interest to create a deployment team where these questions could be brought... Well, at the end we talking about two not-so-similar schemes: developer - deployment/QA/releases/etc - user and developer/doer - user/doer In my mind, sugar by nature is 2nd, but 1st scheme is also important (OLPC, XO, SOAS). But strive for only 1st scheme, imho, is pretty wrong way. Everything I'm doing is from a man who are from 2nd scheme: * more decentralized deployment (0sugar) * more decentralized development (polyol) * more decentralized collaboration (Activity_Library activity [5] [6]) I'm sure 2nd scheme is not less important (at least), and more appropriate to community-driven projects like sugar (not sugar like an OS on XO). Like it or not, Sugar gets used because someone deploys it, and in 99.9% of the cases it's not the final user who deploys it. If we pretend otherwise, Sugar won't reach users in an optimal way and we are failing to aim for our stated goals. I'm not saying that 1st is less important then 2nd, I meant that 2nd should grow. btw w/ 0install entirely sugar could (will, after implementing Saccharin distro, 0install based sugar) be installed on most of GNU/Linux distrobutions. I still think that having a default journal makes sense and that having alternative implementations would hurt Sugar deployability. From that derives that the default Journal should be actively developed, specially as fundamental parts of it are still unimplemented. I also think that if deployers discussed with you their needs and you had a more direct knowledge of how your work impacts learners you would change your mind. In any case, it's awkward that we are having this discussion because I don't have the authority to speak in behalf of deployers. I don't think it's entirely your fault, because deployers are trusting that SLs' maintainers will guess what they need without them having to get involved, which is the root cause of this problem. Well, maybe my first steps on 2nd way were affected by lack of communication w/ real deployments, but for now, it is my deliberate intention. And this worries me, but I think I understand your position. Regards, Tomeu -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
On Fri, May 07, 2010 at 12:28:33PM +0200, Tomeu Vizoso wrote: On Fri, May 7, 2010 at 12:18, Aleksey Lim alsr...@member.fsf.org wrote: On Fri, May 07, 2010 at 12:04:38PM +0200, Tomeu Vizoso wrote: On Fri, May 7, 2010 at 11:56, Aleksey Lim alsr...@member.fsf.org wrote: On Fri, May 07, 2010 at 11:15:12AM +0200, Tomeu Vizoso wrote: On Fri, May 7, 2010 at 11:05, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, May 06, 2010 at 05:13:38AM -0300, Andrés Ambrois wrote: On Thursday 06 May 2010 02:14:44 am you wrote: On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote: If you think Journal development should be halted until it is moved out of glucose, we should get working on that; deployments need this feature. To be honest, I didn't think about it at all. I have only one simple idea, create more functional journal and give a chance to users to use it on 0.82+ sugars. With journal only in glucose, only 0.90 users will get features like thumbs view, with activity based scheme (since I'm planing to support 0.82+ in journal library) all users (keeping in mind that current stable OLPC release is 0.82, next stable will be 0.84) all of XO users will have a chance to use new journal like activities. Thus, in my mind, library journal is more important. I'm worried about how this could affect deployments negatively, but as we don't have a forum for developers to discuss these subjects with them... Well, at the end polyol/libjournal for me are experimental projects that could be somehow part of glucose, but they couldn't be as well because they are designed to be glucose agnostic. IMHO, you as a maintainer shouldn't take such a decision without making at least some efforts to make sure you aren't jeopardizing the ability of downstreams to pick up future versions of Sugar. I know it's very hard right now for developers like you to get that feedback, but unfortunately there doesn't seem to be enough interest to create a deployment team where these questions could be brought... Well, at the end we talking about two not-so-similar schemes: developer - deployment/QA/releases/etc - user and developer/doer - user/doer In my mind, sugar by nature is 2nd, but 1st scheme is also important (OLPC, XO, SOAS). But strive for only 1st scheme, imho, is pretty wrong way. Everything I'm doing is from a man who are from 2nd scheme: * more decentralized deployment (0sugar) * more decentralized development (polyol) * more decentralized collaboration (Activity_Library activity [5] [6]) I'm sure 2nd scheme is not less important (at least), and more appropriate to community-driven projects like sugar (not sugar like an OS on XO). Like it or not, Sugar gets used because someone deploys it, and in 99.9% of the cases it's not the final user who deploys it. If we pretend otherwise, Sugar won't reach users in an optimal way and we are failing to aim for our stated goals. I'm not saying that 1st is less important then 2nd, I meant that 2nd should grow. btw w/ 0install entirely sugar could (will, after implementing Saccharin distro, 0install based sugar) be installed on most of GNU/Linux distrobutions. I still think that having a default journal makes sense and that having alternative implementations would hurt Sugar deployability. libjournal is not about not having journal in glucose, it is just about developing journal like activities that are based on libjournal, glucose could be based on libjournal as well. From that derives that the default Journal should be actively developed, specially as fundamental parts of it are still unimplemented. Don't see problems in developing such thing in libjournal, moreover, libjournal based activities will be more cutting edge projects since they will be developing by small groups of coders. I also think that if deployers discussed with you their needs and you had a more direct knowledge of how your work impacts learners you would change your mind. In any case, it's awkward that we are having this discussion because I don't have the authority to speak in behalf of deployers. This brings us to situation when we have *only* 2nd scheme. IMHO, sugar should grow in both ways and I don't see problems (due to limited of resources and hugeness of task) if some of sugar related developers will be concentrated only on one scheme. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
On Thursday 06 May 2010 02:14:44 am you wrote: On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote: snip 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. Hi Aleksey. Thanks for taking the time to look at this. While I personally don't think it's that hard to collaborate on the ml, I believe this discussion belongs in the Code Review process changes thread [0]. Either way, the bug I referred to (#1915) contains the previous discussion and links to both patchsets. It is also tagged as r?, though no one has taken a look at it yet. I should say that the fact that you commented on this thread before you did so on the ticket is evidence that reviewing patches here managed, at worst, to grab the right person's attention, and at best will work the same for others. But I digress. I think your opinion is important and should be part of that thread. 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. If you share this thinking, please come aboard. I'm not convinced, but I could be. While I think opening up the API might encourage activity developers to produce their own (potentially better) journal UI's, I feel it is a mistake to stop improving the canonical interface for accessing the user's data: it is orthogonal; we can work on improving the current UI _and_ provide the tools you mention. If you think Journal development should be halted until it is moved out of glucose, we should get working on that; deployments need this feature. On the other hand, the Journal was once an activity but was integrated into the shell in 0.84 (see commit f0ff3b) for performance and maintainability reasons, have any of those priorities changed in your mind? I've taken a look at some of the components of your Polyol project and I'm impressed by the quality and quantity of your work, congrats!. Having covered all the above, I thing only datastore patch is requested. You mean only the DS patch will be accepted? [3] http://wiki.sugarlabs.org/go/Activity_Team/Services/Journal -- Aleksey [0] http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023410.html -- -Andrés signature.asc Description: This is a digitally signed message part. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
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. If you share this thinking, please come aboard. Having covered all the above, I thing only datastore patch is requested. [3] http://wiki.sugarlabs.org/go/Activity_Team/Services/Journal [0] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Extended_list_view_palette [1] http://bugs.sugarlabs.org/ticket/1915 [2] 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 toolbar. 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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.
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 [0] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Extended_list_view_palette [1] http://bugs.sugarlabs.org/ticket/1915 [2] 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 toolbar. 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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
