[Sugar-devel] [RELEASE] Paint-25

[Sugar Labs Activities]

Url:
http://activities.sugarlabs.org/addon/4082

Release notes:
See activity page

Reviewer comments:
Trusted activity


Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Unbootable machine

[H. Peter Anvin]

Jonas Smedegaard wrote:
>>
>>> Also look for how you have configured your BIOS... some Award BIOSes
>>> have USB-ZIP, USB-HDD, USB-FDD configurations; you generally want USB-HDD.
> 
> In my (older non-Sugar) experience, USB-HDD is best, then USB-ZIP, and 
> if none of those options are available then pick USB-FDD (which is then 
> most likely names something else).
> 

This is absolutely the order of preference.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Unbootable machine

[H. Peter Anvin]

Bernie Innocenti wrote:
>>
>> Equally weird.  The only "standard" ones are 64 heads, 32 sectors and
>> 255 heads, 63 sectors.
> 
> Shouldn't fdisk guess these values automagically?
> And, more importantly, who are we going to blame if it doesn't? ;-)
> 

I don't know.  It might be an fdisk issue; Linux fdisk has *always*
behaved in this way, but I haven't looked at that code at all.

-hpa
-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Unbootable machine

[H. Peter Anvin]

Bernie Innocenti wrote:
> On 06/02/09 03:43, H. Peter Anvin wrote:
>> Bernie Innocenti wrote:
>>> Disk /dev/sdb: 2055 MB, 2055208960 bytes
>>> 221 heads, 2 sectors/track, 9081 cylinders
>> I don't know where fdisk, the Linux kernel, or whatever come up with
>> these kinds of geometries.  They're almost universally non-bootable.
> 
> Ok, I wiped mbr and made fdisk create a new one:
> 
> Disk /dev/sdb: 2055 MB, 2055208960 bytes
> 64 heads, 62 sectors/track, 1011 cylinders
  ^^

Equally weird.  The only "standard" ones are 64 heads, 32 sectors and
255 heads, 63 sectors.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Unbootable machine

[H. Peter Anvin]

Bernie Innocenti wrote:
> Disk /dev/sdb: 2055 MB, 2055208960 bytes
> 221 heads, 2 sectors/track, 9081 cylinders

I don't know where fdisk, the Linux kernel, or whatever come up with
these kinds of geometries.  They're almost universally non-bootable.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Unbootable machine

[H. Peter Anvin]

Caroline Meeks wrote:
> Luke and Sasha are working on a new USB format that they feel will allow
> more machines to boot and support VM + Stick
> 
> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/USB_format
> 
> Perhaps the issue you are running into (which we have definitely seen
> before) is related to some of the ones they are looking at and part of
> why they need two boot partitions that are slightly different.
> 

I don't understand why 128 heads.  64 heads is the more compatible version.

I presume the notion of partition 1 and 4 is to deal with things that
have an odd notion of zipdisks.  I have personally not seen any devices
which will only boot with partition 1 or only with partition 4, if you
have any such information I would appreciate it.

Part of me also wonders if using EXTLINUX might not be easier for you, too.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Unbootable machine

[H. Peter Anvin]

Bernie Innocenti wrote:
> Hello Peter & Jeremy,
> 
> I've found an ordinary desktop PC (with Phoenix Award BIOS 6.00PG) that
> won't boot off a USB stick created by livecd-tools-024 with syslinux
> (tested both versions 3.75 and 3.81).
> 
> The boot process drops to the "boot:" prompt with an error message:
> 
>   could not find kernel image: linux
> 
> The same USB stick boots fine on any other computer I could find.
> Does it seem like a syslinux bug?  And if turns out to be a known BIOS
> bug, is there a good workaround?
> 

I need much more details; *all* Award BIOSes make in the past 10-12
years have version number 6.00PG.

Also look for how you have configured your BIOS... some Award BIOSes
have USB-ZIP, USB-HDD, USB-FDD configurations; you generally want USB-HDD.

There are some BIOSes which will boot from USB *only* if it was
formatted with 64 heads, 32 sectors; apparently due to some odd notion
that only zipdrives would be USB.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] HTML Canvas performance in the Browse activity

[Mihai Sucan]

Hello Tomeu!


Le Sun, 31 May 2009 20:10:49 +0300, Tomeu Vizoso  a  
écrit:

> On Sun, May 31, 2009 at 18:48, Mihai Sucan  wrote:
>> Hello everyone!
>>
>> I am Mihai Sucan, and I am working over the summer to develop and
>> integrate a paint tool [1] into Moodle. [2] I am also involved in doing
>> performance testing on the XO laptop.
>
> Thanks a lot for your nice work untangling this mess. I'm forwarding
> this email to sugar-devel because I guess you want the Sugar
> developers be aware of this.

You're all welcome. ;)


> Let me ask you a couple of questions:
>
> - which version(s) of Sugar targets your project?

I am not intimate with the development cycle and work-flow of the OLPC XO.  
I learned sufficiently to see it's Fedora Core-based, and that Sugar is  
becoming distro agnostic.

Thus, my answer is simply limited to my current usage of the XO. I want  
PaintWeb to work well on the OLPC XO-1 laptop, with the latest stable OS  
release (that's 8.2.1).


> - already have an idea about how are going to be deployed any
> modifications that result from this?

The modifications resulting from this work are already deployed into  
PaintWeb. You can try the last working SVN trunk snapshot at:

http://www.robodesign.ro/paintweb/trunk/src/paintweb.html

The paintweb.js file contains the updateCanvasScaling() function which  
does the Canvas scaling.

The application is working fine on the XO.


Best regards,
Mihai


-- 
Mihai Sucan
http://www.robodesign.ro
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Localization] Help activity

[Yama Ploskonka]

Seth Woodworth wrote:

>   The point of having the Help 
> activity as its own icon was to put it as close and easy to the user as 
> possible.  There was a goal of having the help activity or similar 
> introduction run on first boot, but we ran out of time in the 8.2 release.

Thank you for bringing this in, Seth.

I've been asking a while for at least a first boot - better an opt-out
always-after-boot for Help, just like win 95 on

As is now, an inconspicuous icon among many, low usability score.

BTW, I would want to see a simple way to bind an activity to boot, Help 
is not the
only candidate for that treatment, other options would range from some 
infomercial,
part of G1G1, and local choices.

Yama





___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] TamTam Mini-51

[Sugar Labs Activities]

Url:
http://activities.sugarlabs.org/addon/4061

Release notes:
See activity page

Reviewer comments:
Trusted activity


Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ANNOUNCE] Email announcements from activities.sugarlabs.org

[Aleksey Lim]

Hi all,

Since now activities.sugarlabs.org will use email notifications to
announce new releases. So activity developer needs only upload new
activity/new-activity-version, fill in release notes field and this
information will be sent to sugar-devel@ mailing list.

--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [GSoC] progress report

[Benjamin M. Schwartz]

Lucian Branescu wrote:
> Also, now I'm more inclined to do the dbus functionality through
> pyxpcom, mostly because of security issues. This
> http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes
> would provide dbus accessibility directly to javascript and I'd need
> to handle security around that.

Personally, I recommend that you not worry about this.  Sugar is designed
with the assumption that Activities can be arbitrary untrusted code, and
so they are run in jails that prevent them from taking actions not
explicitly permitted by the user.  This includes various kinds of D-Bus
actions.

I am not knowledgeable about the present state of D-Bus isolation in
Rainbow, but if it is insufficient it should be fixed in Rainbow, not in
the browser.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Searchable Tagging

[kartik rustagi]

Hello,

I have started working on adding the feature of "Search able tags" to Sugar.
This will allow
the users to tag them self or any else in the network. These tag will be
generalized tags. Users
 will have the option to search for users having a particular tag. Say for
example I tag my self
 as : "I love python". Then if a user in the network searches for "python",
the result will show
me. Here are some of the use cases (contributed by tomeu):
*
Use case 1*: Finding people with similar interests:
Pepe enjoyed during the weekend his first rock climbing experience and would
like to find other
people in his school who also like it.
*
Use case 2*: Limiting the mesh view to a subset defined locally:
Maria is a teacher and would like that during her classes, only her students
in that class appear in
 the mesh view.

*Proposed user experience*

*Use case 1*: finding people with similar interests:
Pepe tags itself as climbing, and when someone searches in the mesh view for
"climbing", Pepe will
 appear in the results.
*
Use case 2*: limiting the mesh view to a subset defined locally:
Maria tags each of the students in that class with the tag "my_class", so
that when searches in the
mesh view for that text, only her students appear. In the case that someone
else has tagged himself
with that same tag, it will appear as well in the results, but will be
marked differently as the local matches.

 As it can be seen, this feature will be a precursor to add "Groups" to
Sugar.  I am right now trying to
 add these tags to /source/sugar-presence-services/src/buddy.py and try to
read these using D-Bus interface.

Feedback and suggestions are requested. If some one wants to add some new
and interesting use case, they
can do it at: http://wiki.sugarlabs.org/go/Tagging_Proposal

ps: I have ejabberd set up in my system and wanted to know how to use gadget
on it. If any one has done some
thing similar, please let me know.

-- 
Regards
Kartik Rustagi
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [SoaS] New Snapshot: Activity Updates

[Sebastian Dziallas]

Hi everybody,

I'm really happy to announce this new snapshot, which brings you quite 
some changes, compared to the last version. So what's waiting for you?

* Fixed DPI size issue on the XO - should look better now

* Included Library and Tux Paint; updated Record activity

* updated Turtle Art to the latest version - thanks to Bryan & Walter

As always, please report issues you encounter. Here are the new links:

Live Image: 
http://download.sugarlabs.org/soas/snapshots/2/Soas2-200906031834.iso

Virtual Appliance: 
http://download.sugarlabs.org/soas/appliances/soas2-20090603.zip

Boot Helper: http://people.sugarlabs.org/sdz/soas-boot-20090603.iso

Thanks and happy testing,
--Sebastian
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [GSoC] progress report

[Lucian Branescu]

Since I missed the meeting, here goes.

I've had a really hectic past few days, with 2 exams, just getting my
laptop back and constantly fighting my Uni network restrictions. But
it's better now, finished with exams and I figured out how to trick
the proxies.

I played around with a template Site Specific Browser based on Browse,
almost identical up to now. I think I have SSB generation mostly
figured out, I need to start implementing it. I will probably have to
either change the existing bookmark mechanism or add a new one,
because bookmarks (specifically bookmarklets) should be part of data,
not state.

I also tried Tomeu's technique for getting Gears to work, but that
xulrunner bug prevents any permissions being granted. My initial plan
was to test Gears with GMail, but it's not quite possible right now.
I'll look into it, but I'd rather not have to build xulrunner.

Also, now I'm more inclined to do the dbus functionality through
pyxpcom, mostly because of security issues. This
http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes
would provide dbus accessibility directly to javascript and I'd need
to handle security around that. Since my dbus needs are limited, I
prefer to instead do everything python-side and inject javascript
objects that do simple things (notifications, sounds, etc.). Of
course, dbus is still a secondary objective.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] GASP - summer internship

[Benjamin M. Schwartz]

Jamie Boisture wrote:
"""
One of the problems with using gtk in this way is that gtk.main() can not
be called when begin_graphics is called because it would not allow the
rest of the user's program to execute.  Instead it has to launch a thread
that will update the screen and call gtk.main_iteration().  This is not
ideal, but I do not see an alternative.
"""

There's nothing wrong with using threads for drawing; there's even a
tutorial on how to do it right on the Cairo website. [1]  Section 20 of
the PyGTK FAQ is also helpful. [2]

However, you can avoid threading while maintaining a responsive user
interface, even if rendering is slow.  The trick is to break rendering up
into many small steps, and switch control back to the mainloop between
steps.  This way, if the user makes an action, there will not be a long
delay before the mainloop can process the input.

This programming style is sometimes called a "coroutine".  There's a nice
example at [3], which is also referenced in PyGTK FAQ 20.9.

--Ben

[1] http://cairographics.org/threaded_animation_with_cairo/
[2] http://faq.pygtk.org/
[3] http://www.daa.com.au/pipermail/pygtk/2001-October/002056.html

P.S.  In practice, I doubt this will be a problem.  If users only get
input feedback once a new frame is rendered, then it hardly matters how
quickly their input is received.  Therefore, you can probably render whole
frames at once, single-threaded, and just not worry about it.



signature.asc
Description: OpenPGP digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] GASP - summer internship

[Jamie Boisture]

Hello All,

I'm going to be working on porting GASP from pygame to pycairo as a summer
internship.  Here is a link to the project description:

http://docs.google.com/View?id=dgv2st82_167gwpnw6dw

I would appreciate any advice you can give me.  I'm would also like to
integrate it into pippy because it would be a really powerful educational
tool.

Thanks,
Jamie Boisture
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Fwd: [Bugs] #925 HIGH: Scratch is not sugarized

[Gary C Martin]

On 3 Jun 2009, at 13:53, Caroline Meeks wrote:

> Hi,
>
> Should this bug really get closed or is there some other state it  
> could be in?

I'd say a trac ticket must have a real named owner to be of any use.

> Sugarizing Scratch is clearly a legitimate feature request.

It's more an onerous task, than a feature request ;-) There nothing  
coders (and you need to find a willing coder) hate more than having to  
poke around someone else's code to make it work right...

> I'm not saying sdz should do it this week, but if someone came along  
> and wanted to do something this task should definitely be on the  
> list of tasks a Sugar volunteer could do.
>
> Where do we keep track of requests like Sugarizing Scratch?

You could add it to the bottom of this Activity Team page:

http://wiki.sugarlabs.org/go/Activity_Team/TODO

Regards,
--Gary

> -- Forwarded message --
> From: SugarLabs Bugs 
> Date: Wed, Jun 3, 2009 at 2:39 AM
> Subject: Re: [Bugs] #925 HIGH: Scratch is not sugarized
> To:
> Cc: b...@lists.sugarlabs.org
>
>
> #925: Scratch is not sugarized
> -- 
> +-
>Reporter:  davidjim   |  Owner:  sdz
>Type:  defect | Status:  closed
>Priority:  High   |  Milestone:  Unspecified by  
> Release Team
>   Component:  SoaS   |Version:
>Severity:  Major  | Resolution:  notsugar
>Keywords:  scratch sugarized  |   Distribution:  SoaS
> Status_field:  New|
> -- 
> +-
> Changes (by erikos):
>
>  * status:  new => closed
>  * version:  0.84.x =>
>  * resolution:  => notsugar
>  * milestone:  0.84 => Unspecified by Release Team
>
>
> Comment:
>
>  Scratch is not included in a build. This is not a Soas bug. Of  
> course it
>  would be nice to have it better integrated. Please check with the  
> upstream
>  maintainers.
>
> --
> Ticket URL: 
> Sugar Labs 
> Sugar Labs bug tracking system
> ___
> Bugs mailing list
> b...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/bugs
>
>
>
> -- 
> Caroline Meeks
> Solution Grove
> carol...@solutiongrove.com
>
> 617-500-3488 - Office
> 505-213-3268 - Fax
> ___
> 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] More information on font scaling problem

[James Simmons]

I mentioned before that I'm having a font sizing problem on the XO 
running .82.  When I set a font on a textviewer it looks OK running 
under sugar-devel or SoaS by is *much* larger on the XO.  This is the 
code I'm currently using:

self.scrolled = gtk.ScrolledWindow()
self.scrolled.set_policy(gtk.POLICY_NEVER, gtk.POLICY_AUTOMATIC)
self.scrolled.props.shadow_type = gtk.SHADOW_NONE
self.textview = gtk.TextView()
self.textview.set_editable(False)
self.textview.set_cursor_visible(False)
self.textview.set_left_margin(50)
self.textview.connect("key_press_event", self.keypress_cb)
buffer = self.textview.get_buffer()
buffer.connect("mark-set", self.mark_set_cb)
self.font_desc = pango.FontDescription("sans %d" % style.zoom(10))
self.textview.modify_font(self.font_desc)
self.scrolled.add(self.textview)
self.textview.show()
self.scrolled.show()
v_adjustment = self.scrolled.get_vadjustment()
self.clipboard = gtk.Clipboard(display=gtk.gdk.display_get_default(), 
selection="CLIPBOARD")
self.page = 0
self.textview.grab_focus()

The "sans 10" font is really too small for SoaS but on the XO it makes 
80 columns of text fill the width of the screen.  Any ideas?

James Simmons




___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Request for Artwork: Boot Screen

[Christian Marc Schmidt]

Hi Sean--these look great! Of the mockups, I think this one works the best:

"Variant of XO Avatar Sugar Boot, Grey to Colour Dot Transition"

It really is very effective, and the color helps a lot!


Christian


On Mon, Jun 1, 2009 at 9:33 PM, Sean DALY  wrote:
> Here's the second mockup:
> http://wiki.sugarlabs.org/go/Marketing_Team/Boot_Logo#Eleven_Color_Ray_Variant.2C_Growing_XO_Avatar.2C_Starts_With_Logo_Splash_Page
>
> This version includes a logo/copyright splash page and a "growing" or
> "approaching" XO avatar.
>
> Comments welcome please.
>
> thanks
>
> Sean
>
>
> On Tue, Jun 2, 2009 at 1:20 AM, Sean DALY  wrote:
>> http://wiki.sugarlabs.org/go/Marketing_Team/Boot_Logo#Eleven_Color_Ray_Variant_of_XO_Avatar_Sugar_Boot.2C_Grey_to_Color_Transition
>>
>> I've finally updated the wiki with my first mockup! Sorry about the
>> delay, I lack graphics editing skills I'm afraid.
>>
>> I have attached comment to the mockup. I keep the XO avatar size
>> stable in this first one, I want to try another one with growing size
>> as expressed yesterday.
>>
>> Note: the idea is this follows a previous page with Sugar logo,
>> version info, copyright notice, and distro logo (+ possibility of
>> school logo). I will try to work those into my next mockup.
>>
>> The spectrum colors were cheerfully eyedropped from an image of
>> Ellsworth Kelly's painting "Spectrum IV" (1967), with the
>> particularity that I thought it interesting to cycle from XO green
>> (mockup green darker than should be, sorry)
>>
>> thanks
>>
>> Sean
>>
>>
>>
>>
>> On Mon, Jun 1, 2009 at 2:07 AM, Christian Marc Schmidt
>>  wrote:
>>> Thanks Sean--a visual would be good to fully understand the proposal.
>>> I guess my feeling on all of this is that less is more--as Eben said
>>> earlier, the boot sequence is really just the set-up for the UI. I'd
>>> be happy if we simply did away with the split-XO, but I'm also
>>> on-board with adding a bit of color, though I would caution not to
>>> overthink it. The reason the Mac OS boot sequence you mention works so
>>> well is due to its simplicity. Instead of a face, we have the XO as
>>> our emblem--and the circle, while making a reference to connectedness
>>> and community, transitions into a core feature of the UI in Home...
>>>
>>> Either way, looking forward to seeing your mockups!
>>>
>>>
>>> Christian
>>>
>>>
>>> On Sun, May 31, 2009 at 5:54 PM, Sean DALY  wrote:
 I like Gary's most recent one with the dots filling in color

 I got halfway through a mockup with XO avatars appearing, then
 Activity icons, but I feel using either will just be too confusing...
 one could think network discovery was happening, or Activity loading.

 After much reflection, I think the friendliest greeting we could offer
 to Learners is a face, a Speakish one with eyes rolling around the
 ring (and a growing smile) while the colors come on. There are still
 many people who fell in love with their little Macs because of the
 smiley face.

 But... that's outside the Sugar HIG and I would think twice before
 stepping outside of that. So I reread them and came up with this idea
 (which I hope to mock up tomorrow): instead of dots, I want to do
 oblong ovals like a big version of the Activity spinner graphic. I
 searched high and low on sl.o and laptop.org for an SVG but only found
 a lo-res PNG :-( so I'll just improvise ovals. What I like about
 presenting the spinner is: immediate identification of a waiting
 period, no confusion with other elements (the filled in dots are too
 similar to networks in the Neighborhood view). Also I like that the
 spinner has 11, not 12 dividers; that asymmetry is interesting and
 remains clocklike. I like Gary's proposal of empty ones filled with
 color which I'd like to keep. And... I'd like to start the middle XO
 icon small (e.g. neighborhood view size) and step it up in size with
 each spinner step; grow in importance as the system builds, until at
 the end normal size.

 As for the colors, I'm not sure I like the color pairs... I'd like to
 try solid colors, moving through the spectrum rainbowlike. Less
 Sugarish perhaps, but visually stronger might be.

 Not sure if the initial logo flash is enough, but concerned that
 keeping it around might fight the spinner ring.

 Will have a visual tomorrow to show (holiday so I will have some time)

 thanks

 Sean

 On Sat, May 30, 2009 at 10:50 PM, Christian Marc Schmidt
  wrote:
> On Sat, May 30, 2009 at 12:58 PM, Sean DALY  wrote:
>> Re: grey vs. colors in progress: Actually, I have an issue with
>> all-grey... users could worry that colors are not working in the Sugar
>> UI.
>
> If we treated the XO in the center in the selected color combination,
> we would not only address Sean's point, but also act as a signifier of
> identity. But I take

[Sugar-devel] Fwd: [Bugs] #925 HIGH: Scratch is not sugarized

[Caroline Meeks]

Hi,

Should this bug really get closed or is there some other state it could be
in?

Sugarizing Scratch is clearly a legitimate feature request. I'm not saying
sdz should do it this week, but if someone came along and wanted to do
something this task should definitely be on the list of tasks a Sugar
volunteer could do.

Where do we keep track of requests like Sugarizing Scratch?

-- Forwarded message --
From: SugarLabs Bugs 
Date: Wed, Jun 3, 2009 at 2:39 AM
Subject: Re: [Bugs] #925 HIGH: Scratch is not sugarized
To:
Cc: b...@lists.sugarlabs.org


#925: Scratch is not sugarized
--+-
   Reporter:  davidjim   |  Owner:  sdz
Type:  defect | Status:  closed
   Priority:  High   |  Milestone:  Unspecified by Release
Team
  Component:  SoaS   |Version:
   Severity:  Major  | Resolution:  notsugar
Keywords:  scratch sugarized  |   Distribution:  SoaS
Status_field:  New|
--+-
Changes (by erikos):

 * status:  new => closed
 * version:  0.84.x =>
 * resolution:  => notsugar
 * milestone:  0.84 => Unspecified by Release Team


Comment:

 Scratch is not included in a build. This is not a Soas bug. Of course it
 would be nice to have it better integrated. Please check with the upstream
 maintainers.

--
Ticket URL: 
Sugar Labs 
Sugar Labs bug tracking system
___
Bugs mailing list
b...@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/bugs



-- 
Caroline Meeks
Solution Grove
carol...@solutiongrove.com

617-500-3488 - Office
505-213-3268 - Fax
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel