Re: [Sugar-devel] [ANNOUNCE] Sucrose 0.84 Feature Freeze
Greg Smith wrote: Hi Simon, I looked at the schedule. Its helpful but I'm not sure I fully understand all the milestones. What is the definition of final release? This is the golden image. It is the last coordinated release. After that we only deliver updates for components. Once the feature set is frozen, how do I know what is in the release? Each release in the cycle has it's release page with the relevant features and fixes for the specific release. After Feature Freeze we might wrap up what big changes/features went in, in the announcement. Is that the list of Trac IDs in 0.83.1 release notes? Would be the sum of the releases in the cycle before the feature freeze. (btw the bug ID URLs on that page link to the wrong Trac system). Fixed. Also, are all XO relevant bugs tracked in the OLPC Trac bug system: (dev.laptop.org)? dev.laptop.org should have bugs that are only relevant to the OLPC platform in the future. Currently, I guess there are still some bugs that other distributions would profit as well. Are you joining our weekly 9.1.0 meeting (Wed. at 2PM US ET IRC on freenode.net #olpc-meeting)? I take this as an invitation - and will try :) I don't have it on the schedule for this week but I think we should put a synch up with Sugar schedule discussion on the agenda ASAP. Time left is short for this release. What we are currently working on can be seen in our development TODO list http://sugarlabs.org/go/DevelopmentTeam/TODO. Stability is a top priority for XO users. The only way I know of to improve stability is lots of testing time and focus on bug fixes. We need to get that scheduled soon if we want a new sugar release in XO Software Release 9.1.0 in March. That is why we set the feature freeze in mid January - that we have 6 weeks left to stabilize. By January I hope to have the BugSquad [1] then in place to handle all the incoming bug reports from testing. My impression is that we made a big step forward on improving stability in 8.2.0. I hope we can do it again. Sure :) Thanks, Greg S Best, Simon [1] http://sugarlabs.org/go/BugSquad ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Sucrose 0.84 Feature Freeze
Hi Simon, Thanks for the follow up! You are definitely welcome at every 9.1 planning meeting as is everybody who is interested in working on the next major software release for the XO. Consider yourself personally invited :-) I added a line to the 9.1.0 schedule to note 0.83 freeze. See: http://wiki.laptop.org/go/9.1.0_requirements#Schedule That schedule needs a lot of work which I hope we can track in our weekly meeting. On this: dev.laptop.org should have bugs that are only relevant to the OLPC platform in the future. Currently, I guess there are still some bugs that other distributions would profit as well I'm still not quite clear. Let me ask it this way. I want to list, triage, prioritize and track all the important bugs for XO Software Release 9.1.0. That includes the Sugar bugs. Which trac system do I use for that? Maybe both? On release notes, features and this: Time left is short for this release. What we are currently working on can be seen in our development TODO list http://sugarlabs.org/go/DevelopmentTeam/TODO. Our QA needs to know what bugs and features will be in the release before the release is done in order to be able to test them in advance. If I understand correctly, you only post the feature list in the release notes after its final. Where can I get a list of things that QA (volunteer or otherwise) should test before we finish? Let me know if those questions are not clear or you need any more info. BTW I'm not complaining. Your documentation is definitely getting better and I appreciate the work everyone is doing. I'm just trying to work out the details so we can make another quality release. Thanks, Greg S PS - Should this thread be on the OLPC devel list? Can you post your Sugar announcements stuff to that list? That way I can reply there and try to conform to Tomeu's list usage strictures. (kidding about strictures T-man, I'm just trying to do the right thing :-) Simon Schampijer wrote: Greg Smith wrote: Hi Simon, I looked at the schedule. Its helpful but I'm not sure I fully understand all the milestones. What is the definition of final release? This is the golden image. It is the last coordinated release. After that we only deliver updates for components. Once the feature set is frozen, how do I know what is in the release? Each release in the cycle has it's release page with the relevant features and fixes for the specific release. After Feature Freeze we might wrap up what big changes/features went in, in the announcement. Is that the list of Trac IDs in 0.83.1 release notes? Would be the sum of the releases in the cycle before the feature freeze. (btw the bug ID URLs on that page link to the wrong Trac system). Fixed. Also, are all XO relevant bugs tracked in the OLPC Trac bug system: (dev.laptop.org)? dev.laptop.org should have bugs that are only relevant to the OLPC platform in the future. Currently, I guess there are still some bugs that other distributions would profit as well. Are you joining our weekly 9.1.0 meeting (Wed. at 2PM US ET IRC on freenode.net #olpc-meeting)? I take this as an invitation - and will try :) I don't have it on the schedule for this week but I think we should put a synch up with Sugar schedule discussion on the agenda ASAP. Time left is short for this release. What we are currently working on can be seen in our development TODO list http://sugarlabs.org/go/DevelopmentTeam/TODO. Stability is a top priority for XO users. The only way I know of to improve stability is lots of testing time and focus on bug fixes. We need to get that scheduled soon if we want a new sugar release in XO Software Release 9.1.0 in March. That is why we set the feature freeze in mid January - that we have 6 weeks left to stabilize. By January I hope to have the BugSquad [1] then in place to handle all the incoming bug reports from testing. My impression is that we made a big step forward on improving stability in 8.2.0. I hope we can do it again. Sure :) Thanks, Greg S Best, Simon [1] http://sugarlabs.org/go/BugSquad ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] About the default ogg player in sugar
[changed to sugar-de...@sugarlabs.org] On Wed, Dec 17, 2008 at 11:39, Kushal Das kushal...@gmail.com wrote: Hi, Still now the WebActivity handles the ogg files (audio/video). I am looking forward to have Jukebox activity to handle these mime types. From the current mime.defaults: application/ogg org.laptop.WebActivity audio/ogg org.laptop.WebActivity video/ogg org.laptop.WebActivity Hi Kushal, will try to set aside some time tomorrow for playing with your activity, but in the meantime, what's your personal opinion on this? Is there anything that worked better in Sugar without Jukebox? Which are the biggest issues in Jukebox right now and where do you plan to work next? Eben, could you please install it and give your opinion? Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Sucrose 0.83.3 Tarballs Due the 18th December
On Wed, Dec 17, 2008 at 22:24, Simon Schampijer si...@schampijer.de wrote: Simon Schampijer wrote: Dear Sucrose maintainers, please provide source tarballs for the Sucrose 0.83.3 Development Release by the end of the 18th of December and announce them as explained here: http://sugarlabs.org/go/DevelopmentTeam/Release#Module_release Note that we use http://download.sugarlabs.org now to host the Sucrose sources. The Sucrose maintainers should nearly all have developer accounts with Sugar Labs already. Catch me or bernie on #sugar if you have further questions or problems. More info on the Schedule: http://sugarlabs.org/go/DevelopmentTeam/Release/Roadmap#Schedule Thanks, Your Release Team Just as a little note: there is an hourly script syncing the two machines. So don't be surprised if the package does not show up immediately. Do we just run Marco's release script? Does that upload to shell.sugarlabs.org? Regards Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] activities.s.o update
Tomeu, Can we just check out your tree and have things work? Or should I modify the a.s.o instruction page to reflect how to pull from git.sl.org. Also, please feel free to kill the activities.sugarlabs.org/mainline. I did a git svn from the mozilla repoitory and git push to push the tree into gitorious. We will need to retain the ability to resync changes from mozilla. In the short term I think all of the changes that we push upstream will be as patches uploaded to their bugtracker. thanks david On Thu, Dec 18, 2008 at 1:18 PM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, I'm working on a tree in git.s.o: http://git.sugarlabs.org/projects/activities-sugarlabs-org/repos/aso-tomeu Rebased the patches from https://bugzilla.mozilla.org/show_bug.cgi?id=377513 with last version, but some things changed so much, I'm not sure I didn't broke anything. Have moved now to create a Sugar application and a category for activities and I'm adding the code required to support activities. Plan to keep working on this during the next days. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Working math graphs/plots
Hi Reinier, On 17 Dec 2008, at 08:23, Reinier Heeres wrote: Hi Gary, I'm currently working on updating the Calculator. I built a new expression parser (based on some python internals) that is about 10 times faster. This also makes plotting a whole lot more interesting, since it was a bit slow before. I like the icon you drew; do you have it as an SVG? That one was just a quick mock-up, here's the real SVG :-) inline: plot.svg I'm still not exactly sure where to fit it in, but perhaps I can rename the 'Format' tab to 'Misc' or something, because currently there are not many things there and I can always use a separator. When I was making the plot SVG, I had a quick play folding the Constants (not much in there either) and Formats tab, into a new Miscellaneous tab with some separators: inline: calc-plot-screenshot.jpg Don't have a strong opinion about where Plot should really go (I was just trying to wean out a tab in the above case). Finally, if you have good ideas about how to better expose the help texts I would be really interested too, since I agree with the discussion that they could be better exposed. I think we should lock Eben in a dark broom-cupboard somewhere until he comes up with a suitable HIG way of exposing (some level of) help :-) There seem to be two levels of potential help content: A) activity usage tutorials/walkthroughs; B) help while you're poking your way around a UI. I'm focused on case B here, and for most activities I think B should be enough. Some (likely biased) rambling approaches on the matter, in no particular order: 1) Add a standard help icon to every activities activity tab which brings up a modal sugarised dialogue box with a (scrollable) text view. PROs - visually discoverable - lots of space for lots of text CONs - no space on activity tab for another icon (all that wasted share with... widgetry) - not contextual!!! - modal, so you can't see help and interact with UI!! - I don't find single lumps of help text all that useful/pleasant :-) 2) Add a standard help icon to every activities activity tab, clicking it would make the cursor into a help cursor where the next click on some feature would reveal some help text (Carol hinted at this). PROs - visually discoverable CONs - no space on activity tab for another icon (all that wasted share with... widgetry) - interaction method is a little complicated (changes cursor state, multiple clicks) - would require a lot of retrofitting and you'd still need to visually indicate every item that has have some help otherwise the user is left frustratingly screen scrubbing with a ? cursor, perhaps digging to some UI element that might end up having no help any way (or force developers to add help to every visually distinct pile of pixels so the user always could find at least something). - where does the actual help text appear (a hove pop-up, a help dialogue) 3) The 'Reinier' way, put a help item in a hover palette/menu that reveals help 'in some way'. PROs - context sensitive (and developers only have to add help for complex features) - uses existing Sugar UI features CONs - Edward can't find it ;-b (not so easy to discover due to delayed reveal) - the 'in some way' needs some work. In calculates specific case, inserting a help command into the calculator input is not great as it mangles the formula you were half way through and needed help on. The resulting help text answer display is also pretty truncated just now. I'm still liking option 3 the most. It requires no special sugar inventions, just some HIG from Eben so that activities have a standard style to aim for. Once a few activities use it, you'll know where to look if you need help elsewhere. The 'in some way' could be resolved for a generic activity use case by: 3.1 Make the help item trigger a dialogue of some kind. This could be something new, or even just the non-modal alert dialogue as available in 8.2. PROs - enough room for a sentence or two of help CONs - needs testing, might have odd behaviours in real life – do they stack if you have several alerts open? 3.2 Replace the help item with the actual help text, right there in the palette. PROs - help is just right there, no clicking, no pop-ups! CONs - non-standard use of menu/palette items (relative to other platforms, non functional menu text is frowned upon in most HIGs) - limited quantity of help text (needs to be short and sweet or will look silly) - will be confusing if a palette needs other real working items. Can inactive help text be styled? Italics perhaps? Any other help suggestions out there? Shall we all go open trac tickets for Even and the HIG ;-) Regards, --Gary Cheers, Reinier Gary C Martin wrote: On 13 Dec 2008, at 05:55, Edward Cherlin wrote: On Fri, Dec 12, 2008 at 8:50 PM, Gary C Martin g...@garycmartin.com wrote: On 13 Dec 2008, at 01:53,
Re: [Sugar-devel] [IAEP] Working math graphs/plots
On Wed, Dec 17, 2008 at 3:56 PM, Gary C Martin g...@garycmartin.com wrote: 1) Add a standard help icon to every activities activity tab which brings up a modal sugarised dialogue box with a (scrollable) text view. I have something like this in Finance. It's modeless and it's context sensitive with regard to the 'screen' of the activity. It can be toggled by a button in the Activity toolbar. It was really an experiment to try and help people get through some of the complex financial terminology, but it needs some more work. For more detailed help, I would consider adding a 'More' button to the help box, that when clicked would extend the box down to cover the rest of the screen, and show a scrolling rich-text guide to the activity. I would add an Option 4: 4) Add a help icon to the Activity toolbar which launches Browse, displaying an HTML guide to the activity. Either way, it sounds like a lot more work for the translators. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Working math graphs/plots
On 17 Dec 2008, at 23:56, Gary C Martin wrote: 3) The 'Reinier' way, put a help item in a hover palette/menu that reveals help 'in some way'. PROs - context sensitive (and developers only have to add help for complex features) - uses existing Sugar UI features CONs - Edward can't find it ;-b (not so easy to discover due to delayed reveal) - the 'in some way' needs some work. In calculates specific case, inserting a help command into the calculator input is not great as it mangles the formula you were half way through and needed help on. The resulting help text answer display is also pretty truncated just now. I'm still liking option 3 the most. It requires no special sugar inventions, just some HIG from Eben so that activities have a standard style to aim for. Once a few activities use it, you'll know where to look if you need help elsewhere. The 'in some way' could be resolved for a generic activity use case by: 3.2 Replace the help item with the actual help text, right there in the palette. PROs - help is just right there, no clicking, no pop-ups! CONs - non-standard use of menu/palette items (relative to other platforms, non functional menu text is frowned upon in most HIGs) - limited quantity of help text (needs to be short and sweet or will look silly) - will be confusing if a palette needs other real working items. Can inactive help text be styled? Italics perhaps? For comparison with the previous menu screen shot, here's a shot of a tweaked version of Calculate, where the full help text is placed directly in the menu: inline: new-plot-help2.jpg FWIW: I've just spotted there is precedence for this style of help in the Sugar UI, it's used by Log to describe its Log Collector: Send XO information toolbar feature (allegedly sends logs to a server, does anyone actually use this? sounds like a useful feature). --Gary Any other help suggestions out there? Shall we all go open trac tickets for Even and the HIG ;-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] About the default ogg player in sugar
On Thu, Dec 18, 2008 at 1:09 AM, Tomeu Vizoso to...@sugarlabs.org wrote: [changed to sugar-de...@sugarlabs.org] will try to set aside some time tomorrow for playing with your activity, but in the meantime, what's your personal opinion on this? Is there anything that worked better in Sugar without Jukebox? Which are the biggest issues in Jukebox right now and where do you plan to work next? About anything worked better in Sugar without the Jukebox, I don't have much idea on that. Can not find any such difference. Biggest issues in Jukebox: * The volume control button goes to highest position if someone clicks on it after changing the volume once * Catching the keypress events properly, currently if you fullscreen and then come back , spacebar stops working to control the play/pause Focus on the correct widget is the problem I guess. * Currently if some one double click on the jukebox icon fast , it opens two instances of Jukebox, it should always check if any running instance is there, if not then only start. Do we have any existing logic to handle this situation ? TODO: * Drag and drop media objects from Frame * Option to open any other media file while it is running * Playlist making and editing support * Screenshot support * journal support * Collaboration support Kushal -- http://fedoraproject.org http://kushaldas.in ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
