Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
Eben transferred this ticket to Sugar saying he's OK with these
changes. Can someone review please?
I can email support@ or sugar@ or other mailing lists (suggestions
welcome) about corrdinating the wiki / other documentation changes
once that's done.
Martin
On Tue, Apr 29, 2008 at 09:45:06PM +0100, Martin Dengler wrote:
---
src/view/keyhandler.py | 25 -
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 306bb21..219cc5e 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -40,26 +40,25 @@ _actions_table = {
'F4' : 'zoom_activity',
'F9' : 'brightness_down',
'F10': 'brightness_up',
-'ctrlF9' : 'brightness_min',
-'ctrlF10' : 'brightness_max',
+'altF9': 'brightness_min',
+'altF10' : 'brightness_max',
'F11': 'volume_down',
'F12': 'volume_up',
-'ctrlF11' : 'volume_min',
-'ctrlF12' : 'volume_max',
+'altF11' : 'volume_min',
+'altF12' : 'volume_max',
'alt1' : 'screenshot',
-'altf' : 'frame',
'0x93' : 'frame',
'0xEB' : 'rotate',
-'altr' : 'rotate',
-'altq' : 'quit_emulator',
'altTab' : 'next_window',
-'altn' : 'next_window',
-'ctrlaltTab' : 'previous_window',
-'altp' : 'previous_window',
-'ctrlEscape' : 'close_window',
-'ctrlq': 'close_window',
+'altshiftTab': 'previous_window',
+'altEscape': 'close_window',
'0xDC' : 'open_search',
-'alts' : 'say_text'
+# the following are intended for emulator users
+'altshiftf' : 'frame',
+'altshiftq' : 'quit_emulator',
+'altshifto' : 'open_search',
+'altshiftr' : 'rotate',
+'altshifts' : 'say_text',
}
J_DBUS_SERVICE = 'org.laptop.Journal'
pgpWVGbDDPDLf.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Browse - copy Image to clipboard under rainbow
On Sun, Jun 8, 2008 at 11:44 AM, Simon Schampijer [EMAIL PROTECTED] wrote:
Hi,
tomeu can you verify that patch?
Use case: Copying an image using the palette under rainbow.
We loose the data which exist in the filename, should we try to store this
somehow?
Hi,
good catches, what about:
-file_name = urlparse.urlparse(self._url).path
-extension = None
+file_name = os.path.basename(urlparse.urlparse(self._url).path)
if '.' in file_name:
-extension = file_name.split('.')[1]
-fd, self._temp_file = tempfile.mkstemp(suffix='.' + extension)
+base_name, extension = file_name.split('.')
+extension = '.' + extension
+else:
+base_name = file_name
+extension = ''
+
+temp_path = os.path.join(activity.get_activity_root(), 'instance')
+fd, self._temp_file = tempfile.mkstemp(dir=temp_path, prefix=base_name,
+ suffix=extension)
os.close(fd)
+os.chmod(self._temp_file, 0644)
This way we specify the dir we want to save to, preserve the base file
name, and make sure it's unique by using mkstemp.
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] Sugar Digest 2008-06-09
=== Sugar Digest === It has been a busy week for Sugar Labs. 1. Sucrose: On behalf of the Release Team, Simon Schampijer announced Sucrose 0.81.2 (Development Release). Features of this new release include elimination of some platform dependencies, an improved activity-list view, a graphical user interface to the Sugar control panel (including settings for Frame activation delays), and expanded internationalization of Etoys. The next development release is scheduled in two weeks. Thanks to everyone who made this release possible! (Please refer to http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.2 for detailed release notes.) XO users can test the release by updating to joyride-2024 (Please see http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2024/). 2. Governance: One of the challenges that free and open-source projects face is the impact of governance on their community members: while FOSS licenses assure access to source code, that doesn't guarantee a successful project. A governance model can help ensure that the project is run in a professional, disciplined, and equitable manner. Good governance lets the community engage in discourse and provides a transparent mechanism for arbitration in the hopefully rare circumstances in which it is necessary. Some attributes that are necessary for good governance include: meritocracy, transparency of process, open access to anyone who has demonstrated the skills to contribute, and a means to ensure a balance of control so that no one special interest wrests control of either the discourse or the decision-making. A draft proposal for a governance model for Sugar Labs has been posted to the wiki (Please see http://wiki.sugarlabs.org/go/SugarLabs:Governance). Community input and feedback is important: please help us get this done properly. Feel free to make corrections and comments in the wiki or on the IAEP list. 3. It's an education project: This week has also seen a discussion of the educational mission of Sugar Labs in the main-stream media and blog-sphere—a refreshing change of pace from the focus on hardware. You can keep tabs on some of the threads by visiting the Press section of the wiki (Please see http://wiki.sugarlabs.org/go/Press#Sugar_in_the_news). 4. Help Wanted: Sugar Labs was created to provide a mechanism for supporting the Sugar community of volunteers. These volunteers are engaged in a variety of activities: some are writing software to improve Sugar; some are porting Sugar to new platforms; some are developing new activities that run in Sugar; some are helping to debug Sugar and help with quality assurance; some are writing documentation for Sugar developers and for those who use Sugar in the field; some are developing new scenarios for learning with Sugar; some are using Sugar and reporting upon their experiences to the community; and some are providing help and support. Since we started Sugar Labs, we have been receiving a number of requests for help: porting Sugar to new distributions; tuning Sugar on a specific hardware platform; developing specific Sugar activity; helping with support in specific deployments, etc. In order to expedite these requests, a new section in the wiki (http://wiki.sugarlabs.org/go/Sugar_help). 5. Wiki: David Farning continues to make great progress in organizing and fleshing out the Sugar Labs wiki. He has moved a great deal of the Sugar documentation over from wiki.laptop.org and is in the process of finishing up the translation menus and importing of some missing images. In support of the Developer Team, he is setting up an automated API documentation generator set up as well as jhbuild. He is seeking some help from the learning community to set up the Education Team pages (Please see the stub at http://wiki.sugarlabs.org/go/EducationTeam). === Community jams and meetups === ===Tech Talk=== 6. Developer meetings: Weekly sugar developers meetings were restarted this past week; meetings are Thursdays at 17:00 (UTC) on irc.freenode.net, on the #sugar-meeting channel (Please see http://wiki.sugarlabs.org/go/DevelopmentTeam/Meetings). You are invited to join; please add topics that you'd like to discuss (Instructions are in the wiki at http://wiki.sugarlabs.org/go/DevelopmentTeam/Meetings#How_to_add_topics). 7. Review process: Simon Schampijer has written up notes about the code-review process (Please see http://wiki.sugarlabs.org/go/DevelopmentTeam/CodeReview). 8. Auto-documentation: As mentioned above, David Faring has put together an alpha version of an automated API documentation system (Please see http://www.sugarlabs.org/~dfarning/). The APIs are generated using epydoc, which only documents Python files; any C code (or other languages) are not documented. 9. Activities: Simon reports that a new version of the log-activity has been released (You can download the source from http://dev.laptop.org/pub/sugar/sources/log-activity/Log-9.tar.bz2 and the bundle from
[sugar] Proposed Governance - was: (Re: [IAEP] Sugar Digest 2008-06-09)
2. Governance: One of the challenges that free and open-source projects face is the impact of governance on their community members: while FOSS licenses assure access to source code, that doesn't guarantee a successful project. A governance model can help ensure that the project is run in a professional, disciplined, and equitable manner. Good governance lets the community engage in discourse and provides a transparent mechanism for arbitration in the hopefully rare circumstances in which it is necessary. Some attributes that are necessary for good governance include: meritocracy, transparency of process, open access to anyone who has demonstrated the skills to contribute, and a means to ensure a balance of control so that no one special interest wrests control of either the discourse or the decision-making. A draft proposal for a governance model for Sugar Labs has been posted to the wiki (Please see http://wiki.sugarlabs.org/go/SugarLabs:Governance). Community input and feedback is important: please help us get this done properly. Feel free to make corrections and comments in the wiki or on the IAEP list. In general, I like what I see. I think somewhat more (and somewhat less) specific governance needs to be specified from what I see so far. Not all of these need to be addressed in a temporary working governance document, but do need to be addressed in permanent governance documents, and those need to exist in finite time, and ratified by the membership. Clearly, if we're to go the Software Freedom Conservancy route, some of the legal boilerplate overhead one finds in documents such as the Gnome Foundation bylaws Bylaws are not needed. (http://foundation.gnome.org/about/bylaws.pdf). But some other issues should be covered are not currently in the governance document: for example: o how the governance document is modified; what determines quorum for such actions o how decisions are appealed o how notice is given of decisions o how do we adopt permanent governance regulations; as these currently are, they can at best be temporary until a membership exists and ratifies a more formal governance document o what to do about removing/recalling members/board members; it is the board that matters most here). o how vacancies are filled o limits on board membership by employer o how money is disbursed. Again, many of these issues don't matter when things are working well; but if/when disputes arise, having mechanisms for fixing the problem in advance removes much of the heat from the system. Establishing procedures people find transparent and fair in the middle of controversy is very difficult. Some particular critiques: 1) I don't think so many (or maybe any) committees need to be hard-wired in the governance document, particularly at the current size of the project. Instead, I'd recommend making it clear that the oversight board can form committees, and how they can be dissolved. Using the list that exists as examples of what sort of things are envisioned is fine, of course. In Gnome, for example, when I was serving on the board there was no standing community committee; but each conference (organized by different sets of people in different parts of the world) had its own organizing committee that started up before the event, and ran somewhat over; IIRC, the BOD in that case just selected the group holding Guadec and got occasional reports of how the organization of the meeting was proceeding, as part of the BOD oversight role. We found in X.org that getting rid of committees that weren't doing anything was a headache (along with the overhead we had in the bylaws for choosing those committee members). We had an elected technical board which ended up not doing anything; getting rid of it was a headache as it was enshrined in the bylaws, which then had to be amended, which was a PITA. 2) Specifying that meetings be online is a mistake; there will likely be times that other sorts of meetings take place of the oversight board, and you don't want to make that impossible. 3) The decision panel mechanism seems cumbersome, and fraught with political danger; if people don't believe the oversight board is being fair, they should get rid of the oversight board. There is the (possible) issue of how to evaluate technical decisions in dispute if the board ends up less technical than many projects (which might in fact be the long term outcome we'd like to see in Sugar). Some mechanism that permits the board to delegate decision authority (or solicit advice) may be useful. It might just be the same committee mechanism, if committees are easy to establish/de-establish. In a (technical) meritocracy, often many of the people *best* able to judge the technical merits of technical controversy end up serving on the board, and I think it a mistake to forbid oversight board members from serving on such committees. In
Re: [sugar] [PATCH] Browse - copy Image to clipboard under rainbow
Tomeu Vizoso wrote:
On Sun, Jun 8, 2008 at 11:44 AM, Simon Schampijer [EMAIL PROTECTED] wrote:
Hi,
tomeu can you verify that patch?
Use case: Copying an image using the palette under rainbow.
We loose the data which exist in the filename, should we try to store this
somehow?
Hi,
good catches, what about:
-file_name = urlparse.urlparse(self._url).path
-extension = None
+file_name = os.path.basename(urlparse.urlparse(self._url).path)
if '.' in file_name:
-extension = file_name.split('.')[1]
-fd, self._temp_file = tempfile.mkstemp(suffix='.' + extension)
+base_name, extension = file_name.split('.')
+extension = '.' + extension
+else:
+base_name = file_name
+extension = ''
+
+temp_path = os.path.join(activity.get_activity_root(), 'instance')
+fd, self._temp_file = tempfile.mkstemp(dir=temp_path,
prefix=base_name,
+ suffix=extension)
os.close(fd)
+os.chmod(self._temp_file, 0644)
This way we specify the dir we want to save to, preserve the base file
name, and make sure it's unique by using mkstemp.
Thanks,
Tomeu
Yes - this is great! Pushed to git master and tested on the xo as working.
Simon
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Proposed Governance - was: (Re: [IAEP] Sugar Digest 2008-06-09)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Gettys wrote: | 3) The decision panel mechanism seems cumbersome, and fraught with | political danger; if people don't believe the oversight board is being | fair, they should get rid of the oversight board. There is the | (possible) issue of how to evaluate technical decisions in dispute if | the board ends up less technical than many projects (which might in fact | be the long term outcome we'd like to see in Sugar). | | Some mechanism that permits the board to delegate decision authority (or | solicit advice) may be useful. It might just be the same committee | mechanism, if committees are easy to establish/de-establish. | | In a (technical) meritocracy, often many of the people *best* able to | judge the technical merits of technical controversy end up serving on | the board, and I think it a mistake to forbid oversight board members | from serving on such committees. In short, while there may be | circumstances where such a panel is needed, I suspect as currently | proposed, the decision panel being enshrined in governance is a mistake; | and we can use the general committee mechanism to handle the cases where | it may be needed. As the instigator of this Decision Panel business, I should attempt to clarify the idea. My goal is to make serving on the Oversight Board as unappealing as possible. Ideally, it should be _difficult_ to find seven people willing to serve on the Oversight Board. As such, the document specifies that members of the Oversight Board _cannot_ decide controversial issues. It also specifies that members of the Oversight Board _must_ act as secretaries, taking minutes for every meeting of every committee. Oversight Board members are also prohibited from voting in any of the committee meetings, even though they must attend to take minutes (that's been part of the draft from the beginning). I hope this will be a very frustrating experience for members of the Oversight Board. I am a firm believer that the worst people to give power are those who want it. The Oversight Board, as described so far, has the responsibility of keeping Sugar Labs running smoothly, but almost no power to decide the interesting issues. This makes me very happy, as the Oversight Board is therefore most likely to attract people who are interested only in keeping Sugar Labs running, not pushing a particular personal agenda, even a technical agenda. My hope is that people will be elected based on a history of being calm, focused, personable, and reasonable, not on the basis of any platform (they don't have the power to execute it) or technical knowledge (they can't use it). I would much rather keep the technical experts _out_ of governance until a technical decision must be made that requires domain-specific expert knowledge. Most technical decisions should be made on the mailing lists anyway; only issues that must be decided in order for work to continue, and on which the community is otherwise deadlocked, should be escalated to a Decision Panel. I expect the Oversight Board to be concerned almost exclusively with the mundane details of managing finances and partnerships, making sure the communications channels are open, etc. I do not want the Oversight Board to be a Court of Last Resort. I still favor the presence of the Decision Panels section in the draft, but that's not surprising. I see it as an easy lightweight system for moving political issues away from the Oversight Board. I welcome other perspectives. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhNTY0ACgkQUJT6e6HFtqRf/wCfbxVOReVm1u0PKZOdPc6ClgBu 4ukAoIRfEGck6TBcIy8hOYzkv/DiVsn9 =1hDU -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Proposed Governance - was: (Re: [IAEP] Sugar Digest 2008-06-09)
On Mon, 2008-06-09 at 11:07 -0400, Jim Gettys wrote: In general, I like what I see. I think somewhat more (and somewhat less) specific governance needs to be specified from what I see so far. Not all of these need to be addressed in a temporary working governance document, but do need to be addressed in permanent governance documents, and those need to exist in finite time, and ratified by the membership. Clearly, if we're to go the Software Freedom Conservancy route, some of the legal boilerplate overhead one finds in documents such as the Gnome Foundation bylaws Bylaws are not needed. (http://foundation.gnome.org/about/bylaws.pdf). But some other issues should be covered are not currently in the governance document: for example: o how the governance document is modified; what determines quorum for such actions o how decisions are appealed o how notice is given of decisions o how do we adopt permanent governance regulations; as these currently are, they can at best be temporary until a membership exists and ratifies a more formal governance document o what to do about removing/recalling members/board members; it is the board that matters most here). o how vacancies are filled o limits on board membership by employer o how money is disbursed. Again, many of these issues don't matter when things are working well; but if/when disputes arise, having mechanisms for fixing the problem in advance removes much of the heat from the system. Establishing procedures people find transparent and fair in the middle of controversy is very difficult. Some particular critiques: 1) I don't think so many (or maybe any) committees need to be hard-wired in the governance document, particularly at the current size of the project. Instead, I'd recommend making it clear that the oversight board can form committees, and how they can be dissolved. Using the list that exists as examples of what sort of things are envisioned is fine, of course. In Gnome, for example, when I was serving on the board there was no standing community committee; but each conference (organized by different sets of people in different parts of the world) had its own organizing committee that started up before the event, and ran somewhat over; IIRC, the BOD in that case just selected the group holding Guadec and got occasional reports of how the organization of the meeting was proceeding, as part of the BOD oversight role. We found in X.org that getting rid of committees that weren't doing anything was a headache (along with the overhead we had in the bylaws for choosing those committee members). We had an elected technical board which ended up not doing anything; getting rid of it was a headache as it was enshrined in the bylaws, which then had to be amended, which was a PITA. 2) Specifying that meetings be online is a mistake; there will likely be times that other sorts of meetings take place of the oversight board, and you don't want to make that impossible. 3) The decision panel mechanism seems cumbersome, and fraught with political danger; if people don't believe the oversight board is being fair, they should get rid of the oversight board. There is the (possible) issue of how to evaluate technical decisions in dispute if the board ends up less technical than many projects (which might in fact be the long term outcome we'd like to see in Sugar). Some mechanism that permits the board to delegate decision authority (or solicit advice) may be useful. It might just be the same committee mechanism, if committees are easy to establish/de-establish. In a (technical) meritocracy, often many of the people *best* able to judge the technical merits of technical controversy end up serving on the board, and I think it a mistake to forbid oversight board members from serving on such committees. In short, while there may be circumstances where such a panel is needed, I suspect as currently proposed, the decision panel being enshrined in governance is a mistake; and we can use the general committee mechanism to handle the cases where it may be needed. - Jim Walter, Jim I just looked at some other project's bylaws. The eclipse bylaws(1) cover a lot of the points raised by Jim. Thanks Dfarning 1 http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003_11_10% 20Final.pdf ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] python imports and performance (was Re: #5549 ...)
Hi, moving to the list as has little to do with the ticket in question. http://dev.laptop.org/ticket/5549 Comment(by mstone): This seems like a terrible argument to me because of the categorical imperative: if everyone blindly followed style guidelines without making a conscious assessment of the costs imposed by those guidelines then we'd wind up... where we are today, with Python activities that import 10 seconds worth of code before becoming interactive. Thus, while you're correct that we should place a high value on following conventions, I happen to think that the 'imports at the top' guideline has been so badly discredited by its effect activity startup time as to be untenable in the presence of python modules which perform arbitrary computation at import time. (We could also decide to refuse to use python modules which perform noticeable computation on import, but that seems more painful to me. What do you think?) I don't think that you are on crack, but I think that should explain better where you want to go ;) Someone submitted a patch with a violation of the style guidelines. The submitter commented that this violation was made because of performance considerations. I explained why there was no performance hit that would justify that deviance from what is expected the sugar code to look like. What argument are you calling terrible? What has Kant to do with all this? Who is blindly following anything? If activities take X seconds to startup because of module-level code, it has little to do with the imports being at the top or being inline. The modules are loaded because they are imported before the activity window is brought up, and that happens because they are actually needed to perform all the initializations that we want (perhaps mistakenly) to do during activity startup. Now I'm a bit angry at Michael and Chris, because they have managed to drag me again into this old discussion when a little experimentation would have convinced them instead. Just try to move the imports from the top to just before being used, and see if there's any advantage in startup time. Do you really think that I'm so stupid as to have invested so much work on the prefork hack just to avoid shuffling some imports around? In fact, I moved one import to inline when I measured that it actually made a difference (1 second out of 7): http://dev.laptop.org/git?p=sugar-base;a=commitdiff;h=cc7bbec111d691c198ef6c9ca761c8f576882d0a If you can find other modules that are not needed during startup but are actually slowing activity startup, please send patches. I don't expect you to have any problem in having them accepted if you show some evidence of improvements. And for the record, the right fix from my POV is to only register names at the module scope, moving all expensive initializations to be done lazily when things are actually called. Don't know what's the opinion in the python community about this, though. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] python imports and performance (was Re: #5549 ...)
On Mon, Jun 09, 2008 at 12:35:56PM -0400, C. Scott Ananian wrote: p.s. I suspect part of the larger startup issue may be that we are rendering SVGs on demand for the toolbar, etc. We can either defer that rendering, allowing us to open the activity quickly and then later fill in the icons (as the gnome panel does), or maintain a persistent cache of SVG renderings. If this is the case I will work on it immediately. Load-time rendered SVGs should be cached. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal object transfer for 8.2
Tomeu, have heard occasional requests to implement the sending and sharing of journal entries. It's a desirable feature but, from my perspective, it's much lower in immediate priority than work which brings the sugar UI revision into a releasable condition and which polish the existing work by closing several of the 379 tickets assigned to component 'sugar': http://dev.laptop.org/query?status=assignedstatus=newstatus=reopenedcomponent=sugarorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=component So the questions are: is this a feature we should deliver for the 8.2 release? In my opinion, no. Do you think differently? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal object transfer for 8.2
I would argue otherwise. Since Sugar has no control over the robustness of the network, having some way of sharing at a basic level from the Journal is seemingly a high priority. Half of the high-priority bugs in the link you provide are in fact not really Sugar bugs, but subsystem bugs. The others don't seem to be particularly pressing. -walter On Mon, Jun 9, 2008 at 4:12 PM, Michael Stone [EMAIL PROTECTED] wrote: Tomeu, have heard occasional requests to implement the sending and sharing of journal entries. It's a desirable feature but, from my perspective, it's much lower in immediate priority than work which brings the sugar UI revision into a releasable condition and which polish the existing work by closing several of the 379 tickets assigned to component 'sugar': http://dev.laptop.org/query?status=assignedstatus=newstatus=reopenedcomponent=sugarorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=component So the questions are: is this a feature we should deliver for the 8.2 release? In my opinion, no. Do you think differently? Michael ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activities lost star
I upgraded from joyride 2018 to 2024, and then ran Simon's Script (http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.2#Instructions_to_test_in_olpc_joyride). The activities that it upgraded had been starred, but after restarting Sugar, they are no longer starred. I know the script isn't production material, but thought it worth reporting this. Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal object transfer for 8.2
On Mon, Jun 09, 2008 at 04:18:10PM -0400, Walter Bender wrote: I would argue otherwise. Since Sugar has no control over the robustness of the network, having some way of sharing at a basic level from the Journal is seemingly a high priority. My feeling is that since Sugar has no control over the robustness of the network, the feature will function poorly, if at all. Consequently, I would rather see bug-fixes which will bring the system closer to its intended operation with high probability. However, this is just a personal preference. I'm (mostly) happy to release whatever you send my way, so long as it fixes more problems than it creates. Half of the high-priority bugs in the link you provide are in fact not really Sugar bugs, but subsystem bugs. The others don't seem to be particularly pressing. Perhaps a few hours of triage are called for? Here are a few of my favorites: http://dev.laptop.org/ticket/7011 --- Zoom buttons should cycle http://dev.laptop.org/ticket/7220 --- Populate activity ring http://dev.laptop.org/ticket/4236 --- Cancel activity startup http://dev.laptop.org/ticket/7020 --- Force activity shutdown http://dev.laptop.org/ticket/6895 --- Access point UI http://dev.laptop.org/ticket/6909 http://dev.laptop.org/ticket/5444 --- Robustness to failure http://dev.laptop.org/ticket/6148 --- Non-ASCII Activity Names http://dev.laptop.org/ticket/6471 --- Activity startup times http://dev.laptop.org/ticket/6472 http://dev.laptop.org/ticket/6237 --- Cloaked APs http://dev.laptop.org/ticket/6281 --- 802.1x for NY,UY! http://dev.laptop.org/ticket/4877 --- Session API Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal object transfer for 8.2
An OLPC intern would have actually taken up this task, but changed direction for the summer. I 'm not sure though how network robustness will improve if some networking (such as file transfer) is done in the Journal. A slightly more radical change may be necessary ;-) p. Walter Bender wrote: I would argue otherwise. Since Sugar has no control over the robustness of the network, having some way of sharing at a basic level from the Journal is seemingly a high priority. Half of the high-priority bugs in the link you provide are in fact not really Sugar bugs, but subsystem bugs. The others don't seem to be particularly pressing. -walter On Mon, Jun 9, 2008 at 4:12 PM, Michael Stone [EMAIL PROTECTED] wrote: Tomeu, have heard occasional requests to implement the sending and sharing of journal entries. It's a desirable feature but, from my perspective, it's much lower in immediate priority than work which brings the sugar UI revision into a releasable condition and which polish the existing work by closing several of the 379 tickets assigned to component 'sugar': http://dev.laptop.org/query?status=assignedstatus=newstatus=reopenedcomponent=sugarorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=component So the questions are: is this a feature we should deliver for the 8.2 release? In my opinion, no. Do you think differently? Michael ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal object transfer for 8.2
On Mon, Jun 9, 2008 at 10:12 PM, Michael Stone [EMAIL PROTECTED] wrote: So the questions are: is this a feature we should deliver for the 8.2 release? In my opinion, no. Do you think differently? Personally I think we should put it at the very end of the prioritized list of new features: http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap#New_features If someone find time to work in by the feature freeze (20 June), it will be a nice feature to have. But otherwise let's focus to complete the features which are already scheduled for inclusion and on bugfixes. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal object transfer for 8.2
On Mon, Jun 9, 2008 at 10:57 PM, Michael Stone [EMAIL PROTECTED] wrote: On Mon, Jun 09, 2008 at 04:18:10PM -0400, Walter Bender wrote: I would argue otherwise. Since Sugar has no control over the robustness of the network, having some way of sharing at a basic level from the Journal is seemingly a high priority. My feeling is that since Sugar has no control over the robustness of the network, the feature will function poorly, if at all. Consequently, I would rather see bug-fixes which will bring the system closer to its intended operation with high probability. However, this is just a personal preference. I'm (mostly) happy to release whatever you send my way, so long as it fixes more problems than it creates. Half of the high-priority bugs in the link you provide are in fact not really Sugar bugs, but subsystem bugs. The others don't seem to be particularly pressing. Perhaps a few hours of triage are called for? Here are a few of my favorites: After the feature freeze we should definitely spend a good amount of time on bugs triage. The sugar components has not been seriously triaged in the last several months. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
