[Sugar-devel] [Karma] changed jquery.karma.js to use 'name' property instead of ID
Felipe, I changed id property for images, sounds, and surfaces to name instead. Did this to avoid confusion with an html element's ID attribute. I have changed adding_up to reflect this change -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Karma] changed jquery.karma.js to use 'name' property instead of ID
Be careful, name is the historical precursor of id and it's valid in XHTML Transitional for the same purpose. 2009/9/12 Bryan Berry br...@olenepal.org: Felipe, I changed id property for images, sounds, and surfaces to name instead. Did this to avoid confusion with an html element's ID attribute. I have changed adding_up to reflect this change -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ 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] [Karma] changed jquery.karma.js to use 'name' property instead of ID
sure, but we don't use 'name' in the html, only in the API for
referencing particular resources
for example
k.surfaces[scorebox] references the scorebox canvas
k.surfaces[timer] references the timer canvas
k.library.images[ball] references a ball image preloaded in the
following code
k.init({ images [ {name:ball, file:ball.png}],
surfaces[{name:scorebox, canvas:scoreboxCanvas}]
});
On Sat, 2009-09-12 at 08:43 +0100, Lucian Branescu wrote:
Be careful, name is the historical precursor of id and it's valid in
XHTML Transitional for the same purpose.
2009/9/12 Bryan Berry br...@olenepal.org:
Felipe,
I changed id property for images, sounds, and surfaces to name instead.
Did this to avoid confusion with an html element's ID attribute.
I have changed adding_up to reflect this change
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Karma] changed jquery.karma.js to use 'name' property instead of ID
that said, i am tempted to use 'kid' as in 'karma id' to avoid just this confusion On Sat, 2009-09-12 at 08:43 +0100, Lucian Branescu wrote: Be careful, name is the historical precursor of id and it's valid in XHTML Transitional for the same purpose. 2009/9/12 Bryan Berry br...@olenepal.org: Felipe, I changed id property for images, sounds, and surfaces to name instead. Did this to avoid confusion with an html element's ID attribute. I have changed adding_up to reflect this change -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Project Guidelines posted
On Thu, Sep 10, 2009 at 10:34, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Sep 02, 2009 at 03:51:55PM -0500, David Farning wrote: The project guidelines are now on the wiki at http://wiki.sugarlabs.org/go/Sugar_Labs/Project_Guidelines . Please edit as necessary. When it looks like the editing has stopped, I ask the board the ratify the guidelines. Sorry for being late(maybe), but I have one idea in my mind - adding(as option) vote system to Project_Guidelines. The core idea is simple(but powerful) way for getting feedback and getting this feedback keep project ideas in consensus. In some cases poll could be multileveled i.e. not voting for entirely project but step by step elaboration from abstract statements to details of implementations(not unnecessary implementation, it could stop on statement level). So, idea is some kind of community driven process of project evolution. If we have agreement on more abstract level we can step dipper and can avoid situations when someone are disagree because of some points in the middle of entirely idea. Don't know how it could look in implementation details.. maybe wiki plugin, separate activity, utilizing mls and irc. Isn't this related to Brainstorm and Blueprints in Launchpad? http://brainstorm.ubuntu.com/ https://blueprints.launchpad.net/ I personally would be more interested in being the users and deployers who suggest new features, rather than developers. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Calculate toolbars work in progress shots
On 09/12/2009 03:10 AM, Gary C Martin wrote: Hi Eben, On 11 Sep 2009, at 21:01, Eben Eliason wrote: On Fri, Sep 11, 2009 at 3:17 PM, Gary C Marting...@garycmartin.com wrote: Hi Eben, On 11 Sep 2009, at 20:11, Eben Eliason wrote: Looks great! The icons are quite nice. My only suggestion is that (still retaining the modularity!) the misc toolbar actually just be added as another secondary toolbar. That leaves the basic toolbar mostly empty, but that's ok! This is an instance, I think, where all of the basic functionality of the calculator lives outside of the toolbar, and each toolbar adds advanced functionality on top of that. Moreover, misc controls seem to be the worst suited for a primary toolbar, which should instead contain controls that are nearly always useful, or useful in all contexts. Thanks, that's pretty much where I was at but wanted another opinion :-) The one exception (for the future) will I hope be the Plot function. I'd love to see that UI improved via a Secondary toolbar, at the least with a set of standard example graphs for folks to plug in values (now that matplot lib is supported). Yeah, definitely. It would make sense to have a toolbar dedicated to that. I could also see dedicating a toolbar to constants. You've got buttons for a couple of them. Perhaps a few more could be added. If some don't have obvious symbols or frequent use, the constants toolbar could also have a dropdown that read add a constant by default, and contained a list of many with full names to add. A suggested symbol for this would follow the trend of the color and shape icons in the mockup of the Paint activity, which showed a small 2x2 grid of colors and shapes, respectively. I'd use e, pi, phi, and something else. If constants and graphs had their own secondary toolbars, I could see an argument for exposing the display mode in the primary toolbar, since it affects all calculations and could be useful to see at all times. Any suggestions for a Misc icon? ;-) I don't, unfortunately, have a good idea for a generic misc icon. It seems like any option I can think of I would consider bad design, which might be because using the concept of leftovers to group together a set of tools in a toolbar is just a bad idea. Heh. But short of breaking out the functionality as described above (which itself could seem odd without more functions in each toolbar), I don't have a better idea. I could get behind leaving the modes and the graph button up there for now if we could find a few more constants to add to a secondary constants toolbar and leave it at that. What do you think? OK, this is the best I have right now. As you can see, it is just the old Miscellaneous tab content all under an icon (intended for the Constants). If I can wrangle the code tomorrow in a way works for old and new toolbars, I'll add a couple more constants (Golden Ratio, and Euler's Constant) and move Plot, deg/rad, sci/exp, and digits – though I'll have to leave out any string changes for the new constants, so their hover palettes are likely to be an uninformative φ (lowercase Greek letter phi), γ (lowercase Greek gamma): Regards, --Gary I like the misc icon! What does the 9 stand for? Maybe I missed a math class... Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Calculate toolbars work in progress shots
Hi Fred On 12 Sep 2009, at 04:56, Frederick Grose wrote: On Fri, Sep 11, 2009 at 9:10 PM, Gary C Martin g...@garycmartin.com wrote: ... OK, this is the best I have right now. As you can see, it is just the old Miscellaneous tab content all under an icon (intended for the Constants). If I can wrangle the code tomorrow in a way works for old and new toolbars, I'll add a couple more constants (Golden Ratio, and Euler's Constant) and move Plot, deg/rad, sci/exp, and digits - though I'll have to leave out any string changes for the new constants, so their hover palettes are likely to be an uninformative φ (lowercase Greek letter phi), γ (lowercase Greek gamma): The icons look nice. Would it make sense to keep the number base, units, or notation visible on the primary bar at all times? I'll try and move plot, deg, sci, decimal places back up to the primary today, but I was hoping to share identical code with old toolbars vs new toolbars – need to see how minimal I can make any code duplication if I split up this toolbar. Are base 2, 8, 16 number displays supported? No not at the moment, though if you want to file an enhancement trac ticket I could take a look and see how invasive it is to add for a future release. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Calculate toolbars work in progress shots
Hi Simon, On 12 Sep 2009, at 10:45, Simon Schampijer wrote: On 09/12/2009 03:10 AM, Gary C Martin wrote: Hi Eben, On 11 Sep 2009, at 21:01, Eben Eliason wrote: On Fri, Sep 11, 2009 at 3:17 PM, Gary C Marting...@garycmartin.com wrote: Hi Eben, On 11 Sep 2009, at 20:11, Eben Eliason wrote: Looks great! The icons are quite nice. My only suggestion is that (still retaining the modularity!) the misc toolbar actually just be added as another secondary toolbar. That leaves the basic toolbar mostly empty, but that's ok! This is an instance, I think, where all of the basic functionality of the calculator lives outside of the toolbar, and each toolbar adds advanced functionality on top of that. Moreover, misc controls seem to be the worst suited for a primary toolbar, which should instead contain controls that are nearly always useful, or useful in all contexts. Thanks, that's pretty much where I was at but wanted another opinion :-) The one exception (for the future) will I hope be the Plot function. I'd love to see that UI improved via a Secondary toolbar, at the least with a set of standard example graphs for folks to plug in values (now that matplot lib is supported). Yeah, definitely. It would make sense to have a toolbar dedicated to that. I could also see dedicating a toolbar to constants. You've got buttons for a couple of them. Perhaps a few more could be added. If some don't have obvious symbols or frequent use, the constants toolbar could also have a dropdown that read add a constant by default, and contained a list of many with full names to add. A suggested symbol for this would follow the trend of the color and shape icons in the mockup of the Paint activity, which showed a small 2x2 grid of colors and shapes, respectively. I'd use e, pi, phi, and something else. If constants and graphs had their own secondary toolbars, I could see an argument for exposing the display mode in the primary toolbar, since it affects all calculations and could be useful to see at all times. Any suggestions for a Misc icon? ;-) I don't, unfortunately, have a good idea for a generic misc icon. It seems like any option I can think of I would consider bad design, which might be because using the concept of leftovers to group together a set of tools in a toolbar is just a bad idea. Heh. But short of breaking out the functionality as described above (which itself could seem odd without more functions in each toolbar), I don't have a better idea. I could get behind leaving the modes and the graph button up there for now if we could find a few more constants to add to a secondary constants toolbar and leave it at that. What do you think? OK, this is the best I have right now. As you can see, it is just the old Miscellaneous tab content all under an icon (intended for the Constants). If I can wrangle the code tomorrow in a way works for old and new toolbars, I'll add a couple more constants (Golden Ratio, and Euler's Constant) and move Plot, deg/rad, sci/exp, and digits – though I'll have to leave out any string changes for the new constants, so their hover palettes are likely to be an uninformative φ (lowercase Greek letter phi), γ (lowercase Greek gamma): Regards, --Gary I like the misc icon! What does the 9 stand for? Maybe I missed a math class... The 9 icon is an existing feature that changes the number of digits calculated, clicking it cycles between 6, 9, 12, 15. inline: number_of_digits_shown.png Regards, --Gary___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
2009/9/11 Gary C Martin g...@garycmartin.com: On 11 Sep 2009, at 00:30, Eduardo H. Silva wrote: Should the toolbar icon for the colors palette have a down arrow like with the other toolbar button icons? After all, it doesn't execute a primary action of its pallete when clicking, instead it reveals its palette. No, down arrows indicate the new lockable secondary toolbars (one click to lock open, one click to lock closed, hover for temporary quick use like a palette). Locking open secondary toolbars resizes the activity canvas area, normal toolbar palettes do not. FWIW: it has been agreed (I think) that any icons that have _NO_ default primary function (i.e. they just hold palettes) should instantly, and fully expose on a single left click (as they already do for a single right click). As their primary function is to display their palette. Maybe we can solve this for 0.88. This would solve things like providing instant feedback on buddy icons, such as accessing the large self buddy icon in the home view for getting to settings, shutdown etc. But shouldn't something be done visually to differentiate those icons which open palettes when clicked, from those which act their primary action? The user won't know beforehand what will the result of clicking be otherwise. Eduardo Regards, --Gary Eduardo 2009/9/10 Gary C Martin g...@garycmartin.com: On 10 Sep 2009, at 12:01, Aleksey Lim wrote: On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: Hi, currently the ColorButton is not fully clear in it's behavior (see http://dev.sugarlabs.org/ticket/388). Click outside the palette to close it etc. Benjamin suggested to have an ok/cancel button to make the end of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 Do others agree? Other thoughts? Another option is that picker should contain only predefined colors(and maybe one custom) by default and having click-to-close behaviour. Then if users want to make(change) custom color, they click add..(or so) button and palette opens right panel and click on predefined color will just change custom color. btw having select-to-close behavior(at least by default) we will keep things consistent, e.g. to select suboptions from palette menus, user needs only one click. Is it possible to emit the colour change event as soon as a colour is clicked? Or, perhaps emit as soon as the mouse leaves the palette area? I tried some quick mockups, the OK/Cancel doesn't feel very Sugar UI like (no other palettes use this behaviour). The click a colour to dismiss, with the addition of a 'custom colour' icon seems more natural, but looses a current nice feature where by you can pick a preset colour, see the sliders move, and then adjust them if you want to tweak. It also seems a little odd seeing both the toolbar icon and the custom icon changing colour at same time (see attachment below), though I guess in this case the toolbar icon could only change once you make a choice (and as you move a cursor around a document with colours). Anyway, all this makes me think that solving the issue by emitting colour change events early (i.e. not just when palette closes) would be a cleaner solution (more like a bug fix for a current unintended behaviour rather than redesigning an already good UI to avoid it). Regards, --Gary ___ 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] [Design] ColorButton
Or I might be nit-picking... Eduardo 2009/9/12 Eduardo H. Silva hoboprim...@gmail.com: 2009/9/11 Gary C Martin g...@garycmartin.com: On 11 Sep 2009, at 00:30, Eduardo H. Silva wrote: Should the toolbar icon for the colors palette have a down arrow like with the other toolbar button icons? After all, it doesn't execute a primary action of its pallete when clicking, instead it reveals its palette. No, down arrows indicate the new lockable secondary toolbars (one click to lock open, one click to lock closed, hover for temporary quick use like a palette). Locking open secondary toolbars resizes the activity canvas area, normal toolbar palettes do not. FWIW: it has been agreed (I think) that any icons that have _NO_ default primary function (i.e. they just hold palettes) should instantly, and fully expose on a single left click (as they already do for a single right click). As their primary function is to display their palette. Maybe we can solve this for 0.88. This would solve things like providing instant feedback on buddy icons, such as accessing the large self buddy icon in the home view for getting to settings, shutdown etc. But shouldn't something be done visually to differentiate those icons which open palettes when clicked, from those which act their primary action? The user won't know beforehand what will the result of clicking be otherwise. Eduardo Regards, --Gary Eduardo 2009/9/10 Gary C Martin g...@garycmartin.com: On 10 Sep 2009, at 12:01, Aleksey Lim wrote: On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: Hi, currently the ColorButton is not fully clear in it's behavior (see http://dev.sugarlabs.org/ticket/388). Click outside the palette to close it etc. Benjamin suggested to have an ok/cancel button to make the end of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 Do others agree? Other thoughts? Another option is that picker should contain only predefined colors(and maybe one custom) by default and having click-to-close behaviour. Then if users want to make(change) custom color, they click add..(or so) button and palette opens right panel and click on predefined color will just change custom color. btw having select-to-close behavior(at least by default) we will keep things consistent, e.g. to select suboptions from palette menus, user needs only one click. Is it possible to emit the colour change event as soon as a colour is clicked? Or, perhaps emit as soon as the mouse leaves the palette area? I tried some quick mockups, the OK/Cancel doesn't feel very Sugar UI like (no other palettes use this behaviour). The click a colour to dismiss, with the addition of a 'custom colour' icon seems more natural, but looses a current nice feature where by you can pick a preset colour, see the sliders move, and then adjust them if you want to tweak. It also seems a little odd seeing both the toolbar icon and the custom icon changing colour at same time (see attachment below), though I guess in this case the toolbar icon could only change once you make a choice (and as you move a cursor around a document with colours). Anyway, all this makes me think that solving the issue by emitting colour change events early (i.e. not just when palette closes) would be a cleaner solution (more like a bug fix for a current unintended behaviour rather than redesigning an already good UI to avoid it). Regards, --Gary ___ 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
[Sugar-devel] [Feature Freeze] request for exception for Turtle Art
I made a somewhat invasive change to Turtle Art in order to make the
toolbars backward compatible with Sugar 0.82-0.84. Essentially, I
catch an exception when trying to create a ToolbarBox. In the
exception handler, I create the old-style toolbars.
try:
# Use 0.86 toolbar design
toolbar_box = ToolbarBox()
except NameError:
# Use pre-0.86 toolbar design
self.toolbox = activity.ActivityToolbox(self)
self.set_toolbox(self.toolbox)
I had to add a new toolbar for the help menu in the old toolbar
configuration since I had moved the hover help to a toolbar in the
0.86 configuration:
self.helpToolbar = HelpToolbar(self)
self.toolbox.add_toolbar(_('Help'),self.helpToolbar)
So I will request an exception for String Freeze as well.
(I also did a work-around for a Rainbow-related bug with image save.)
Changes are in:
http://git.sugarlabs.org/projects/turtleart/repos/walters-clone
-walter
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
On 12 Sep 2009, at 16:34, Eduardo H. Silva wrote: 2009/9/11 Gary C Martin g...@garycmartin.com: On 11 Sep 2009, at 00:30, Eduardo H. Silva wrote: Should the toolbar icon for the colors palette have a down arrow like with the other toolbar button icons? After all, it doesn't execute a primary action of its pallete when clicking, instead it reveals its palette. No, down arrows indicate the new lockable secondary toolbars (one click to lock open, one click to lock closed, hover for temporary quick use like a palette). Locking open secondary toolbars resizes the activity canvas area, normal toolbar palettes do not. FWIW: it has been agreed (I think) that any icons that have _NO_ default primary function (i.e. they just hold palettes) should instantly, and fully expose on a single left click (as they already do for a single right click). As their primary function is to display their palette. Maybe we can solve this for 0.88. This would solve things like providing instant feedback on buddy icons, such as accessing the large self buddy icon in the home view for getting to settings, shutdown etc. But shouldn't something be done visually to differentiate those icons which open palettes when clicked, from those which act their primary action? The user won't know beforehand what will the result of clicking be otherwise. Yes, I do acknowledge this point, unfortunately all the visual 'cures' I've seen mentioned or tried to think up so far are worse than the 'illness'. The Sugar UI usage of icons with a primary action vs. no primary action would seem to be about 50/50, so any visual treatment would have to look good on ~50% of all icons you see. For the new toolbar lock open/closed 'v' shape, it requires almost all those icons to be re-adjusted/designed from scratch with that extra empty space required below. I guess I'd try to argue for better icon design to start with, so that the author made sure they clearly distinguished icons for single click actions, from icons exposing a palette of actions. Could I ask you indicate some example cases where you see potential confusion? Perhaps we can improve their icon designs. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
2009/9/12 Gary C Martin g...@garycmartin.com: On 12 Sep 2009, at 16:34, Eduardo H. Silva wrote: 2009/9/11 Gary C Martin g...@garycmartin.com: On 11 Sep 2009, at 00:30, Eduardo H. Silva wrote: Should the toolbar icon for the colors palette have a down arrow like with the other toolbar button icons? After all, it doesn't execute a primary action of its pallete when clicking, instead it reveals its palette. No, down arrows indicate the new lockable secondary toolbars (one click to lock open, one click to lock closed, hover for temporary quick use like a palette). Locking open secondary toolbars resizes the activity canvas area, normal toolbar palettes do not. FWIW: it has been agreed (I think) that any icons that have _NO_ default primary function (i.e. they just hold palettes) should instantly, and fully expose on a single left click (as they already do for a single right click). As their primary function is to display their palette. Maybe we can solve this for 0.88. This would solve things like providing instant feedback on buddy icons, such as accessing the large self buddy icon in the home view for getting to settings, shutdown etc. But shouldn't something be done visually to differentiate those icons which open palettes when clicked, from those which act their primary action? The user won't know beforehand what will the result of clicking be otherwise. Yes, I do acknowledge this point, unfortunately all the visual 'cures' I've seen mentioned or tried to think up so far are worse than the 'illness'. The Sugar UI usage of icons with a primary action vs. no primary action would seem to be about 50/50, so any visual treatment would have to look good on ~50% of all icons you see. For the new toolbar lock open/closed 'v' shape, it requires almost all those icons to be re-adjusted/designed from scratch with that extra empty space required below. I guess I'd try to argue for better icon design to start with, so that the author made sure they clearly distinguished icons for single click actions, from icons exposing a palette of actions. Good point. The color button in Write is a good example of that. Could I ask you indicate some example cases where you see potential confusion? Perhaps we can improve their icon designs. To be honest I don't have a use case to show, perhaps it's just a potential problem that doesn't manifest itself. Eduardo Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
On Thu, 2009-09-10 at 18:37 +0100, Gary C Martin wrote: Is it possible to emit the colour change event as soon as a colour is clicked? Or, perhaps emit as soon as the mouse leaves the palette area? The palette change signal is emitted as soon as the palette is closed currently (notify:color is emitted continuously when the color is modified). The idea of emitting the signal slightly earlier, ie. when the mouse leaves the palette, sounds like a good solution to me. It would prevent the issue where one clicks outside the palette and the selection is gone before the color-changed signal is fired. Benjamin 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] [Design] ColorButton
On 12 Sep 2009, at 18:46, Benjamin Berg wrote: On Thu, 2009-09-10 at 18:37 +0100, Gary C Martin wrote: Is it possible to emit the colour change event as soon as a colour is clicked? Or, perhaps emit as soon as the mouse leaves the palette area? The palette change signal is emitted as soon as the palette is closed currently (notify:color is emitted continuously when the color is modified). The idea of emitting the signal slightly earlier, ie. when the mouse leaves the palette, sounds like a good solution to me. It would prevent the issue where one clicks outside the palette and the selection is gone before the color-changed signal is fired. +1, yep that's the use case that's causing us problems currently in Write. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Karma] changed jquery.karma.js to use 'name' property instead of ID
I think things like this will continue happening. I suppose that other libraries have had similar problems and I have not seen a jQuery-id or dojo-id, although that I have not seen them so far does not mean that they don't exist. In this case I would like to continue using id, of course making it very clear that the name we choose is for *internal use* of Karma. btw. When I read kid I think in a little guy, not in a karma-id. 2009/9/12 Bryan Berry br...@olenepal.org that said, i am tempted to use 'kid' as in 'karma id' to avoid just this confusion On Sat, 2009-09-12 at 08:43 +0100, Lucian Branescu wrote: Be careful, name is the historical precursor of id and it's valid in XHTML Transitional for the same purpose. 2009/9/12 Bryan Berry br...@olenepal.org: Felipe, I changed id property for images, sounds, and surfaces to name instead. Did this to avoid confusion with an html element's ID attribute. I have changed adding_up to reflect this change -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org -- Felipe López Toledo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Problem installing and running hulahop on ubuntu 8.10
Hi Tomeu, I apologize for not being able to reply to you for so long. Actually, my mid-semester exams are currently going on and so I would be able to resume my work only after 20th september after they get over. Well, we are pretty much in the dark here so may be good to get a bit more systematic. Yes, sure. Can you remove any traces of hulahop and xulrunner from your system and start anew with only one version of python installed? And also write the series of commands you execute to build it all? I will try this once my exams are over. Also, are you building it in jhbuild? No, I am not building it in jhbuild. Thank You Tomeu for your constant help and support. Regards, VIJIT aka sumit ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar on a Stick v2 Release Naming
Martin Dengler wrote: On Thu, Sep 10, 2009 at 05:30:30PM +0200, Sean DALY wrote: re marketing course: in fact I have accepted Mel's invitation to do a classroom for Fedora. Congratulations. re logos: Strawberry=6, Blueberry=4, and 5 we'll use some other time Very clear - thanks. [Have we agreed on Blueberry as the Name of Record?] Sebastien? So it will be! :) The next release of SoaS will be named Blueberry. Gary, Sean, could any of you give creating a new boot screen with an updated logo for plymouth a try? Thanks, --Sebastian thanks Sean Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar on a Stick v2 Release Naming
On 12 Sep 2009, at 21:40, Sebastian Dziallas wrote: Martin Dengler wrote: On Thu, Sep 10, 2009 at 05:30:30PM +0200, Sean DALY wrote: re marketing course: in fact I have accepted Mel's invitation to do a classroom for Fedora. Congratulations. re logos: Strawberry=6, Blueberry=4, and 5 we'll use some other time Very clear - thanks. [Have we agreed on Blueberry as the Name of Record?] Sebastien? So it will be! :) The next release of SoaS will be named Blueberry. Gary, Sean, could any of you give creating a new boot screen with an updated logo for plymouth a try? Sure no problem, have all the artwork already, just need to swap the colours. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Unifying the Sugar Labs experience Was: [IAEP] Project Guidelines posted
Isn't this related to Brainstorm and Blueprints in Launchpad? Yes, I agree they are closely related. I would like to take a step back and look at the problems we are trying to solve. Backstory. Over the past couple of months I have spent most of my time working with 'external' people and organizations. I have been looking for ways we can work together. Originally, I though of the problem as how do we Identify, Engage, and Empower potential contributors. That is pretty standard volunteer recruitment strategy. This approach has been creating a dissonance that I did not understand until Mel chewed me out last night. The dissonance is that identifying, engaging, and empowering potential contributors flies in the face of nearly everything Sugar Labs stands for. The correct approach is to focus on creating a community culture where potential contributors can discover what they want to do, discover how to engage with the community, and discover how they can implement their ideas. Identify, Engage, and Empower still holds true. Sugar Labs must be discoverable so new contributors can figure out how they fit in. Consistency and clarity of community. In marketing we often talk about the importance of a clear and consistent message. The release cycle is premised around clear and consistent dates for developers to converge and diverge. The way to make Sugar Labs discoverable is to create a clear and consistent community. Creating this consistency does not depend on long weighty legal tomes. In fact, the opposite is true. This consistency comes from clearly sticking to a few guiding principles. Following are three examples of reoccurring situations that happen across the project. #1 A few months ago we were discussing the the pros and cons of updating Sugar via activities.sugarlabs.org. Initially the discussion were heated and rather handwavey. Then the devteam implemented the 'new feature' process. Engaging in the new feature process shifted _all_ of my energy from _proving_ that update is a good idea to creating a viable implementation. The new feature process provided be a very good template for how to proceed if I wanted my feature to be considered for the next release. I filled out the form and hacked together reasonable proof of concept code. One day a core developer, aslroot, pickup the code and rewrote it. A few days later I got a email from Simon asking me to clean up the release notes because it was going to included in .86. The new process guidelines provided me, the inexperienced developer, a way to align my work flow and expectations with the development team. #2 Last Summer we work we several groups of students. Jameson worked with Mel and Leslie Hawthorn on the GSOC project. Fred worked with Prof. Steve Jacobs and I with the RIT co-op students. Our experiences were very different. At RIT we were flying blind. It was the first time: Anyone taught a course combining community service and technology using open source and Sugar. RIT made an exception to allow unpaid co-ops. RIT allow remote co-op. None of us had clear expectations. Communications suffered. GSOC is now in its 5th iteration. They have very good guidelines for how projects can effectually 'identify, engage, and empower' students. Identify - via the project proposal. Engage - via the mentor. Empower - the student is free to explore, collaborate, and reflect within the limits and expectation of the project. #3 Recently the GSOC team brought in $4500. $2000 in travel money and $2500 in general money. The challenge was determining how to spend it. Rather than push this decision up to the oversight board we appointed the GSOC mentors an ad hoc committee who had authority to spend their money as they see fit. The oversight board is in the process of approving this via lazy consensus. By creating a very light weight decision making body of GSOC mentors we pushed the spending authority out to the people with who were highly engaged in the GSOC project. Themes Life cycle guidelines -- The value of life cycle guidelines show up across the project. The new feature process does a very good job of explaining how to take an idea for a new feature through to becoming part of a release. The process makes no judgment on the value of an idea. Instead it aligns expectations of the new developer and the release team. The GSOC guidelines are another variation on life cycle guidelines. It focuses on best practices to help insure that students, mentors, and projects all have matching expectations. Delegating authority -- The oversight board and the ad hoc GSOC spending committee are are both example of delegating authority through lightweight decision making bodies. It took less than ten minutes to set up the committee and get board approval. The decision are being made by those most knowledgeable about the subject. Future action items. Project guidelines -- Project guidelines are just life cycle guidelines for how top
Re: [Sugar-devel] [Karma] changed jquery.karma.js to use 'name' property instead of ID
ok, then do u want me to change it back to just 'id'? On Sat, 2009-09-12 at 13:19 -0500, Felipe López Toledo wrote: I think things like this will continue happening. I suppose that other libraries have had similar problems and I have not seen a jQuery-id or dojo-id, although that I have not seen them so far does not mean that they don't exist. In this case I would like to continue using id, of course making it very clear that the name we choose is for *internal use* of Karma. btw. When I read kid I think in a little guy, not in a karma-id. 2009/9/12 Bryan Berry br...@olenepal.org that said, i am tempted to use 'kid' as in 'karma id' to avoid just this confusion On Sat, 2009-09-12 at 08:43 +0100, Lucian Branescu wrote: Be careful, name is the historical precursor of id and it's valid in XHTML Transitional for the same purpose. 2009/9/12 Bryan Berry br...@olenepal.org: Felipe, I changed id property for images, sounds, and surfaces to name instead. Did this to avoid confusion with an html element's ID attribute. I have changed adding_up to reflect this change -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org -- Felipe López Toledo -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Karma] To do for 0.1 release
Release 0.1 is almost ready Just a couple things need to be done: 1. fix layout of chakra, i.e. mainline/index.html -- Pavel is generously helping w/ this 2. add knavbar to adding_up -- i will try to accomplish this today but may not get it done until some time monday 3. finish article for olpcnews.com, the article will come out on Tuesday. i have a very, very rough draft now 4. Post jsdocs documentation (like Javadoc) to karma.sugarlabs.org/api -- Subzero 5. Take picture of adding_up running on XO -- me I should be able to tag release v 0.1 by tomorrow evening. We only need 1, 2, and 4 to complete the code release. 3 and 5 are just for publicity. Hey guys, we are almost there! pretty exciting since Karma was just a vague idea only a few months ago. There is a lot still to do but we are making steady progress. -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
