Re: [Sugar-devel] On Zeroinstall and Sugar packages

2009-10-20 Thread Sascha Silbe

On Mon, Oct 19, 2009 at 11:42:32PM -0400, Benjamin M. Schwartz wrote:

0compile, combined with Zeroinstall's support for source bundles, 
enables us (1) to approach true platform-independence and (2) to 
provide users the opportunity to modify the source code of a package 
and rebuild it in a natural way.
So unless the sender and receiver architecture match, the receiver needs 
to build the package from source and requires the usual tools (gcc, 
autoconf, etc) for that? How much space would those take up on the XO-1?
I'm not arguing against it, BTW, quite the contrary: I've suggested a 
similar scheme [1] in the past.



[1] 
http://wiki.sugarlabs.org/go/Activity_Team/Packaging_Ideas#combined_Source.2BBinary_package


CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

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


Re: [Sugar-devel] help

2009-10-20 Thread Walter Bender
I have never tried to set the theme in Sugar. Perhaps someone on IRC
has had some experience with it.?

-walter

On Tue, Oct 20, 2009 at 7:11 AM, Esteban Arias
esteban.arias...@gmail.com wrote:
 Hello Walter,

 I need to set contrast theme in the sugar xo.

 when the sistem run, /usr/bin/sugar-shell set the enviroment GTK2_RC_FILES =
 /usr/share/sugar/data/sugar-
 100.gtkrc

 in this path, the sistem apply the theme.

 but this them is apply on only activities Terminal or control panel for
 example. Activities Write or Calculate for example this theme not
 applay.

 I set GTK2_RC_FILES in /etc/enviroment, but persist the problem






-- 
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] help

2009-10-20 Thread Tomeu Vizoso
Hi Esteban,

have you tried editing the gtk-theme-name property in
/usr/share/sugar/data/sugar-100.gtkrc ?

Please reply.

Thanks,

Tomeu

On Tue, Oct 20, 2009 at 12:22, Walter Bender walter.ben...@gmail.com wrote:
 I have never tried to set the theme in Sugar. Perhaps someone on IRC
 has had some experience with it.?

 -walter

 On Tue, Oct 20, 2009 at 7:11 AM, Esteban Arias
 esteban.arias...@gmail.com wrote:
 Hello Walter,

 I need to set contrast theme in the sugar xo.

 when the sistem run, /usr/bin/sugar-shell set the enviroment GTK2_RC_FILES =
 /usr/share/sugar/data/sugar-
 100.gtkrc

 in this path, the sistem apply the theme.

 but this them is apply on only activities Terminal or control panel for
 example. Activities Write or Calculate for example this theme not
 applay.

 I set GTK2_RC_FILES in /etc/enviroment, but persist the problem






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




-- 
«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] [IAEP] Bolzano 2009 - Schedule draft

2009-10-20 Thread Sean DALY
I am pleased to report that I shall be present at Bolzano from late
Tuesday evening the 10th until the evening of the Friday the 13th (!)

While there, with a little help from my friends I wouldn't mind taking
baby steps in Python ;-)

Sean


On Thu, Oct 15, 2009 at 2:24 PM, Simon Schampijer si...@schampijer.de wrote:
 Hi,

 I have posted an initial schedule for the Sugar Camp at Bolzano after
 feedback from Walter, Sebastian, Tomeu, Aleksey and the Zeitgeist
 people. Please let me know, if you have things you want to present that
 are not yet part of the schedule or have any concerns or things I have
 overseen.

 http://wiki.sugarlabs.org/go/Marketing_Team/Events/Sugarcamp_Bolzano_2009#Schedule

 The Saturday and Sunday I have left open for free hacking. Many arrive
 on saturday during the day or on monday. For those there already, use
 the time and work on specific projects.

 Please add yourself to the wiki if you have not done so yet. Note as
 well when you arrive and leave.

 Thanks,
Simon
 ___
 IAEP -- It's An Education Project (not a laptop project!)
 i...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/iaep

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


Re: [Sugar-devel] On Zeroinstall and Sugar packages

2009-10-20 Thread Benjamin M. Schwartz
Sascha Silbe wrote:
 On Mon, Oct 19, 2009 at 11:42:32PM -0400, Benjamin M. Schwartz wrote:
 
 0compile, combined with Zeroinstall's support for source bundles,
 enables us (1) to approach true platform-independence and (2) to
 provide users the opportunity to modify the source code of a package
 and rebuild it in a natural way.
 So unless the sender and receiver architecture match, the receiver needs
 to build the package from source and requires the usual tools (gcc,
 autoconf, etc) for that? How much space would those take up on the XO-1?
 I'm not arguing against it, BTW, quite the contrary: I've suggested a
 similar scheme [1] in the past.

I think my answer is sometimes.  There are many possible scenarios.  For
example, if there is good internet access, and the package maintainer has
compiled the package for many platforms, then the sender only needs to
send the package's name (which is a URL) and then the receiver can install
the arch-appropriate bundle from the internet.  If there is no internet
access, but the sender has kept binaries (and all dependencies) for both
architectures, then the receiver can get all needed binaries from the
sender.  If there is a school server, it can act as a 0mirror [2],
maintaining a cache of many Activity packages, including their
dependencies, for all the school's architectures.  If there is no school
server, and the sender does not have the arch-appropriate packages, the
receiver may use 0share [3] to see if there is anyone else on the network
who has them.  Bundles are GPG-signed for security.

Only after all those things fail do we need to talk about compiling from
source.  Then we have interesting questions like whether it's worth the
space overhead to require all bundles to include source, and whether to
include things like compilers that are needed to rebuild them.  My feeling
is that all Activity bundles should probably come with source code, but
automatically downloading all the build-time dependencies should be a
configuration option that can be disabled on systems with constrained disk
space or bandwidth.

 [1]
 http://wiki.sugarlabs.org/go/Activity_Team/Packaging_Ideas#combined_Source.2BBinary_package

Yeah, what I'm describing is very much like that ... except somebody
already did all the work for us!

[2] http://0install.net/0mirror.html
[3] http://0install.net/0share.html
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


[Sugar-devel] Issues running FoodForce2 on Soas Strawberry

2009-10-20 Thread Mohit Taneja
Hi,

I tried running FoodForce2 on Soas. The game ran fine, but there were some
issues regarding the display of the game, it was too much distorted.
Later I noticed that Soas comes with python 2.6, but I have done most of the
development on python 2.5.4. I ran the game through terminal directly from
the code itself and the following log was generated:

/usr/lib/python2.6/site-packages/sugar/util.py:25: DeprecationWarning: the
 sha module is deprecated; use the hashlib module instead

 import sha
 ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect:
 Connection refused


Any ideas about what could be possible reason for the error?

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


Re: [Sugar-devel] Issues running FoodForce2 on Soas Strawberry

2009-10-20 Thread Mohit Taneja
One more issue which i figured out after a little more debugging is that the
check for Sugar platform is also failing on Soas. I am using the following
check on Soas:


  #Flag to check the operating system
 FLAG_XO = False

try:
import olpcgames, olpcgames.util
if not olpcgames.ACTIVITY: raise RuntimeError
FLAG_XO = True
 except (RuntimeError,ImportError):
 FLAG_XO = False

The same check is working fine on XO1.

Regards,
Mohit Taneja


On Tue, Oct 20, 2009 at 8:25 PM, Mohit Taneja mohitge...@gmail.com wrote:

 Hi,

 I tried running FoodForce2 on Soas. The game ran fine, but there were some
 issues regarding the display of the game, it was too much distorted.
 Later I noticed that Soas comes with python 2.6, but I have done most of
 the development on python 2.5.4. I ran the game through terminal directly
 from the code itself and the following log was generated:

 /usr/lib/python2.6/site-packages/sugar/util.py:25: DeprecationWarning: the
 sha module is deprecated; use the hashlib module instead

 import sha
 ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect:
 Connection refused


 Any ideas about what could be possible reason for the error?

 Regards,
  Mohit Taneja

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


[Sugar-devel] two kinds of delay (was: RFC: Kill the delayed menus for good)

2009-10-20 Thread Albert Cahalan
Michael Stone writes:

 Good suggestion for discoverability, inadequate suggestion for
 fast access to the actually rather important information hidden
 on the secondary palettes (e.g. disk space availability, battery
 status, etc.)

That trumps all.

There are two kinds of delay. Type 1 is stuff like drop-down menus
that remain even if the mouse briefly goes out of bounds. This kind
of delay normally doesn't waste a nanosecond of the user's time.
Type 2 is stuff like start-up animations, sliding menus, and these
delayed menus. Type 2 is in the critical path of user interaction.
It's normally a source of frustration, permanently preventing users
from becoming efficient.

Type 2 delays are almost never acceptable. The only case I can think
of is when something is about to cause a sudden screen change that
may be disorienting to the user. In that case, a very fast transition
effect (perhaps 0.1 second) can help the user follow what is happening.
I doubt the XO-1 hardware is capable of providing this; certainly the
current software situation is far too slow to even attempt it.

Since the delayed menus are a type 2 delay with no excuse, they really
need to go. Right now, users are forced to be essentially incompetent.
You'll never navigate quickly in sugar no matter how proficient you are.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] two kinds of delay (was: RFC: Kill the delayed menus for good)

2009-10-20 Thread Rubén Rodríguez Pérez

 There are two kinds of delay. Type 1 is stuff like drop-down menus
 that remain even if the mouse briefly goes out of bounds. This kind
 of delay normally doesn't waste a nanosecond of the user's time.
 Type 2 is stuff like start-up animations, sliding menus, and these
 delayed menus. Type 2 is in the critical path of user interaction.
 It's normally a source of frustration, permanently preventing users
 from becoming efficient.

The second delay is not only slow, but non-intuitive. I've failed to
discover that functionality myself until someone told me about it. :(

I think, that if the first delay shows only info (a tag, description, or
whatever), and the second one (which for an extra dash of frustration
might exist or not) adds the interaction, it would not harm to simply
show both together in just one small delay.

That way it is easy to use and non obtrusive.

My two cents.


pgpLGSfCf83M8.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Issues running FoodForce2 on Soas Strawberry

2009-10-20 Thread Bobby Powers
do you know which statement is failing in that try statement?  is it the
import olpcgames, import olpcgames.util, or the olpcgames.ACTIVITY access?

bobby

On Tue, Oct 20, 2009 at 1:38 PM, Mohit Taneja mohitge...@gmail.com wrote:

 One more issue which i figured out after a little more debugging is that
 the check for Sugar platform is also failing on Soas. I am using the
 following check on Soas:


  #Flag to check the operating system
  FLAG_XO = False

 try:
 import olpcgames, olpcgames.util
 if not olpcgames.ACTIVITY: raise RuntimeError
 FLAG_XO = True
  except (RuntimeError,ImportError):
  FLAG_XO = False

 The same check is working fine on XO1.

 Regards,
 Mohit Taneja



 On Tue, Oct 20, 2009 at 8:25 PM, Mohit Taneja mohitge...@gmail.comwrote:

 Hi,

 I tried running FoodForce2 on Soas. The game ran fine, but there were some
 issues regarding the display of the game, it was too much distorted.
 Later I noticed that Soas comes with python 2.6, but I have done most of
 the development on python 2.5.4. I ran the game through terminal directly
 from the code itself and the following log was generated:

 /usr/lib/python2.6/site-packages/sugar/util.py:25: DeprecationWarning: the
 sha module is deprecated; use the hashlib module instead

 import sha
 ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect:
 Connection refused


 Any ideas about what could be possible reason for the error?

 Regards,
  Mohit Taneja



 ___
 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] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)

2009-10-20 Thread Albert Cahalan
Eben Eliason writes:

 palettes, we aimed to reduce accidental invocation
 of them without entirely eliminating discovery by increasing the
 delay.
...
 I'm more worried about immediately revealing of all secondary
 actions, which pull attention from the more efficient manner in
 which basic actions can be performed - namely, clicking on the
 big icons.

 If we can do this in a manner which doesn't distract from the
 primary interaction methods and encourage inefficient paths
 through the UI, that would be great.

I believe this was first solved by Kid Pix, a few decades ago.
One button bar swaps out another button bar.

Microsoft's ribbon looks like the same thing, though I've never
used it so I can't say for sure.

Tux Paint certainly uses this model. In that case, it works fine
for kids **way** below sugar's target age. (smart 2-year-old or
regular 4-year-old for sure, possibly younger)

 Another possibility would be to educate children about right click
 somehow.

On the one hand, I think it's really important to do this. Besides
the human-compatibility issue and the extra expressive power, I think
using a second button will help to develop the mind a bit. (you're not
just grabbing or poking when you click; you're performing an action
that could be determined by which button you click)

On the other hand, I think both buttons should be the left button
by default. Kids have trouble hitting the correct button. Button
mistakes should not be something kids face from the moment go.

 Perhaps, as suggested by Wade, we could allude to the availability
 of more information immediately on hover, and perhaps even try making
 the right button the only means of invoking the secondary actions.
 This does work today, but the lack of discoverability is a definite
 problem.

It's no less discoverable than the left button. Right-click menus
need to work two ways though:

a. Press and hold down right button, move, release
b. Click (press and release) right button, move, click either button
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


[Sugar-devel] [RELEASE] sugar-0.86.3

2009-10-20 Thread Aleksey Lim
== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.86.3.tar.bz2

== News ==

* Sporadic freezes while scrolling journal #1506
* Suppress race condition with Journal appearing on sugar startup #1373
* Alt+Space not working to show/hide the tray #1476
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)

2009-10-20 Thread Eben Eliason
On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan acaha...@gmail.com wrote:
 Eben Eliason writes:

 palettes, we aimed to reduce accidental invocation
 of them without entirely eliminating discovery by increasing the
 delay.
 ...
 I'm more worried about immediately revealing of all secondary
 actions, which pull attention from the more efficient manner in
 which basic actions can be performed - namely, clicking on the
 big icons.

 If we can do this in a manner which doesn't distract from the
 primary interaction methods and encourage inefficient paths
 through the UI, that would be great.

 I believe this was first solved by Kid Pix, a few decades ago.
 One button bar swaps out another button bar.

 Microsoft's ribbon looks like the same thing, though I've never
 used it so I can't say for sure.

 Tux Paint certainly uses this model. In that case, it works fine
 for kids **way** below sugar's target age. (smart 2-year-old or
 regular 4-year-old for sure, possibly younger)

Yeah. This is very similar to the now implemented redesign of the
toolbar system for activities, which feedback has indicated is a huge
improvement. However, it doesn't instantly solve the issue for freely
positioned UI elements, such as people and activities within the
various zoom levels. There may be a variation on the technique that
could work in these contexts, of course, and some interesting
possibilities have already been suggested.

 Another possibility would be to educate children about right click
 somehow.

 On the one hand, I think it's really important to do this. Besides
 the human-compatibility issue and the extra expressive power, I think
 using a second button will help to develop the mind a bit. (you're not
 just grabbing or poking when you click; you're performing an action
 that could be determined by which button you click)

 On the other hand, I think both buttons should be the left button
 by default. Kids have trouble hitting the correct button. Button
 mistakes should not be something kids face from the moment go.

Yup. The hardware design was done before a UI team was organized at
OLPC. One of the first suggestions, though it was already too late,
was to limit the hardware to one button.

Since we didn't have the opportunity to change that, we opted to
provide a more traditional right-click functionality both because it
did provide a way to offer more contextual actions in a manner
consistent with other interfaces that already exist, and because we
thought it could actually be perplexing to have two buttons that
always appeared to do the same thing. If that's proving problematic
for children in practice, we could make a change there. I hadn't heard
much on that particular issue, so I don't know how common (or
persistent) it is.

 Perhaps, as suggested by Wade, we could allude to the availability
 of more information immediately on hover, and perhaps even try making
 the right button the only means of invoking the secondary actions.
 This does work today, but the lack of discoverability is a definite
 problem.

 It's no less discoverable than the left button. Right-click menus

True.

 need to work two ways though:

 a. Press and hold down right button, move, release
 b. Click (press and release) right button, move, click either button

Agreed. This would be a good improvement to the behavior.

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


[Sugar-devel] [RELEASE] sugar-toolkit-0.86.2

2009-10-20 Thread Aleksey Lim
== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.86.2.tar.bz2

== News ==

* Do not stop processing motion-notify-event #1507
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Should we care about non readers and kids with motor skill issues?

2009-10-20 Thread Albert Cahalan
Caroline Meeks writes:

 True. But all kids matter. Including the nonreaders, the ones going
 to schools that are not taught in their native language, the ones
 for whom reading is a struggle, the dyslectics.

You don't want to keep them non-readers forever, do you?
That's what happens when you don't push them to use text.

There are 2-year-old kids using Tux Paint. They don't read AFAIK,
yet nearly every Tux Paint icon comes with text. There is even an
area at the bottom of the screen where Tux constantly spews text.

The less a kid is able to read, the more he desperately needs text.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)

2009-10-20 Thread Albert Cahalan
On Tue, Oct 20, 2009 at 4:19 PM, Eben Eliason e...@laptop.org wrote:
 On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan acaha...@gmail.com wrote:
 Eben Eliason writes:

 Another possibility would be to educate children about right click
 somehow.

 On the one hand, I think it's really important to do this. Besides
 the human-compatibility issue and the extra expressive power, I think
 using a second button will help to develop the mind a bit. (you're not
 just grabbing or poking when you click; you're performing an action
 that could be determined by which button you click)

 On the other hand, I think both buttons should be the left button
 by default. Kids have trouble hitting the correct button. Button
 mistakes should not be something kids face from the moment go.

 Yup. The hardware design was done before a UI team was organized at
 OLPC. One of the first suggestions, though it was already too late,
 was to limit the hardware to one button.

The hardware needs two buttons so that it can support
the kid as he grows older. The only button issue I can
see is that there is no space between the buttons; there
should be a gap or the buttons should be on opposite
sides of the track pad. (not that a track pad is OK with
filthy kid fingers)

The software should map the buttons together by default.

Here's a config proposal:

By default, the buttons are mapped together and there
are hover menus. There is a config switch that enables
distinct buttons and changes hover menus to right-click
menus.

Here is an alternate default:

The right button shows an animation of clicking on the
left button or similar, correcting the user. (this is currently
the default for Tux Paint; an adult is expected to change
to both-are-left for 2-year-old kids)

 provide a more traditional right-click functionality both because it
 did provide a way to offer more contextual actions in a manner
 consistent with other interfaces that already exist, and because we
 thought it could actually be perplexing to have two buttons that
 always appeared to do the same thing. If that's proving problematic
 for children in practice, we could make a change there. I hadn't heard
 much on that particular issue, so I don't know how common (or
 persistent) it is.

It's not that they don't understand. Their fingers land in the wrong spot.
They may click right in the middle, hitting both buttons at once.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)

2009-10-20 Thread James Cameron
On Tue, Oct 20, 2009 at 04:40:28PM -0400, Albert Cahalan wrote:
 It's not that they don't understand. Their fingers land in the wrong
 spot.  They may click right in the middle, hitting both buttons at
 once.

I've seen this.

I've a theory.  In other life experiences, kids often have to press at
a spot that gives tactile feedback prior to the press.  Across the front
of the XO those spots include the left edge of the left button, the
right edge of the right button, *and* the interface between the two.

Close your eyes, clear your mind, and run your finger along.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Is Analyze compatible with 0.86.2 Sugar?

2009-10-20 Thread Gary C Martin
Hi Thomas,

On 21 Oct 2009, at 00:30, Thomas C Gilliard wrote:

 I have been using Analyze in several versions of sugar. soas02  
 Fedora 12(rawhide) and trisquel3.0-sugar (ubuntu). both 0.86.2 Sugar
 Analyze seems to work, but I am getting a number of avitars XO where  
 the Pubkey and color fields are filled with ?.
 When this happens, the avitars with ? assume the color of My ./sugar  
 identity. (I may have 4-6 or more showing my colors)
 Bug #1517

 I am not sure if this is due to:
 1.) changes in the presence service from 084 to 086
 2.) a slow and overloaded jabber (this seems to occur when it takes  
 over 1 minute to add an avitar, and there are many users on the  
 jabber.)
 3.) Possibly incompatibility of  the  Analyze  activity with the   
 0.86  versions of Sugar.

 I note that when I use the Activities site and search  for  0.86   
 activities  your  Analyze disappears. But it is present when  all is  
 selected.

 Any help you can give would be appreciated.

Just tested jabber.sugarlabs.org here and with 0.86.1 under an F11  
sugar-jhbuild I'm currently seeing two other buddy icons just as you  
describe (same colour as me, and Analyse lists them with Pubkey=? and  
their colour entries empty) the buddy names were rafael, and  
Gustavo.

My initial gut reaction is that the jabber server is playing up, I  
tried to connect with an XO running 0.84 for comparison but I couldn't  
coax it into connecting at all. I'm also not aware of any presence  
service compatibility breaks in 0.86. One other (slight) possibility  
to consider is perhaps some folks are logged into the server with a  
non-Sugar jabber client, or perhaps a modified version of Sugar. I'll  
try and do some more tests tomorrow.

Anyone else seeing this? I've been working in Salut for a while now  
(~5 local Sugar sessions collaborating) and haven't ever seen this  
particular issue there.

Regards,
--Gary

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


[Sugar-devel] [ASLO] Release XO Help-1

2009-10-20 Thread Sugar Labs Activities
Activity Homepage:
http://activities.sugarlabs.org/addon/4051

Sugar Platform:
from 0.82 to 0.86

Download Now:
http://activities.sugarlabs.org/downloads/version/29286

Release notes:


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] [ASLO] Release XO Help-1

2009-10-20 Thread Sugar Labs Activities
Activity Homepage:
http://activities.sugarlabs.org/addon/4051

Sugar Platform:
from 0.82 to 0.86

Download Now:
http://activities.sugarlabs.org/downloads/version/29286

Release notes:


Reviewer comments:
This request has been approved. 

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

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