date:20100906

Re: [Sugar-devel] Enhancing Sugar to support multiple users

2010-09-06 Thread Tomeu Vizoso

On Mon, Sep 6, 2010 at 02:24, Samuel Klein meta...@gmail.com wrote:
On Sun, Sep 5, 2010 at 5:28 PM, Sascha Silbe
sascha-ml-reply-to-201...@silbe.org wrote:
Excerpts from Christoph Derndorfer's message of Sun Sep 05 21:57:09 +0200
2010:

I just created a new ticket (http://bugs.sugarlabs.org/ticket/2292) to get
some discussions started on what changes need to be made to Sugar to work
well in an environment where multiple users will work on the same machine
(which is how Peru's next 300,000 XOs will be used:
http://www.olpcnews.com/countries/peru/peru_between_one_laptop_per_child_and_seven_children_per_laptop.html
).

I don't think we should change anything in Sugar, for two orthogonal reasons:

1. There is already an existing, proven, well-working mechanism to
support multiple users on the same machine that's way older than
Sugar: user accounts. Check out any computer lab at a university
to see how it works (though I suppose you already know).

Supporting user accounts is not a novel mechanism, and probably
sufficient, but doing it in a Sugar-like way would still benefit from
child-focused design and input. It's something that would be good to
see as part of / a flavor of Sugar one day, rather than as an external
hack by people trying to use Sugar as nature never intended.

I'm confused by this, Sugar's architecture follows closely that of
other modern X11-based desktops which also means it will just work
fine in a multi-user system.

Running parallel instances of Sugar each on its own account is
something that should be completely supported by Sugar's architecture
and not a hack at all.

2. If the Peru government wants Sugar to adapt to being used by multiple
users (in what way exactly?), let _them_ do the work.

The question of the right way to support multiple users on a single
Sugar instance (usb key, computer) is separate from who will do the
work.

(If OTOH you use one account per child, there's nothing to change in
Sugar, so no reason for a ticket).

I don't think you can give Sugar an accountname as a startup
parameter, so there's at least something to change.

When you start Sugar, you are already in an user account, so you don't
really need to give it an username.

What is going to allow the user to choose an account with which to log
in is a display manager and you have several implementations to choose
from. All should work fine with Sugar.

I believe Simon has used this deployment mode in his pilots in Berlin.

Regards,

Tomeu

PS: I know this kind of setup (some 30 computers for the entire school)
from my school days; I've even administered the machines back then. It
was called a computer room (we had two of them). I think you can guess
how much time most pupils spent in there outside of special computer
(i.e. word processing etc.) classes? Computer use in regular subjects
was close to zero, similar to our fancy language lab (a class room
with tape recorders built into desktops) which we used a whopping
two times during my entire school life.

I had similar experiences, though they were well used by a few
students. I'd like to hear more details about what Peru is planning -
which sounds more like a fixed group sharing a computer than that sort
of traditional 'lab'.

--
Samuel Klein identi.ca:sj w:user:sj
___
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] known issues with collaboration in XS 0.5.2

2010-09-06 Thread Tomeu Vizoso

On Fri, Sep 3, 2010 at 19:48, Martin Langhoff mar...@laptop.org wrote:
 On Fri, Sep 3, 2010 at 12:43 PM, Tomeu Vizoso to...@sugarlabs.org wrote:
 I have a local XS 0.6 that is working fine but I'm finding that the XS
 0.5.2 at jabber.sugarlabs.org is not returning some results for some
 of the queries that I make.

 There are very important bugfixes in the final ejabberd that is in
 olpcxs-testing repo for xs-0.6

 I should release a 0.6.1 with the contents of olpcxs-testing, but
 things haven't been kind to me lately.

 You aren't telling us exactly what problems you saw on the old
 ejabberd.

I'm noticing that the server never replies to some PEP queries about
buddyinfo and activity properties. The symptom on the Sugar side is
that the DBus calls timeout.

 All I can say is: that old ejabberd (+patches) had plenty of
 gremlins and unexplainable behaviours. The ejabberd in olpcxs-testing
 has been 100% reliable in behaviour, and I reworked the patches until
 I didn't see any buggy behaviour.

Thanks, this answers perfectly my question.

 Highly recommended. Should work with just a rebuild if you're not on F9.

 I cannot confirm that the right patches are in the latest ejabberd on F13.

Ok, will be keeping an eye on further updates to the School Server
software and will test Sugar against its jabber server.

 cheers,


 m
 --
  mar...@laptop.org -- School Server Architect
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff

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

Re: [Sugar-devel] [Dextrose] Stability stuff

2010-09-06 Thread Tomeu Vizoso

On Fri, Sep 3, 2010 at 23:59, Bernie Innocenti ber...@codewiz.org wrote:
 El Fri, 03-09-2010 a las 11:23 -0400, Martin Abente escribió:

 Well, thats true in theory, assuming all the activities are properly
 designed for sugar. In the field you already know thats not the case.
 Also... even when the activities are being implemented in python
 through the Activity Class, the read and write methods needs to be
 implemented by the programmer. That means it
 depends on the activity specifics again.

 Yes, but if an activity fails to save when Sugar asks it to quit, then
 it's already buggy today: we also have a Stop item in the menu of the
 activity frame icon.


  This is also a very good suggestion. We could start by doing this, which
  is a lot easier and almost equally effective.

 I see it this way: Why waiting to get sick to do something about it.
 Preventive medicine
 is always better. Why waiting for the machine to freeze (waiting 3 or more
 minutes until its back
 to a usable state again) to do something about it, also with potential
 data loss.

 Having a message telling kids that the machine is too overloaded should be
 enough, with
 recommendations about saving any current work and closing earlier
 activities.

 This kind of mechanisms should help to the overall stability, and it makes
 even more sense when you
 think about XO's 1 scenarios.

 :)

 Yes, I already agreed with you on this. The hard part of this patch
 would be setting a threshold to disallow opening another activity.
 Memory footprint of activities varies wildly. Shall we take the worst
 case, pissing off users who knew what they were doing, or shall we be
 optimistic, risking the current behavior in some cases?

 If we also had both the graceful stop on oom that I was thinking of,
 we could afford to be be optimistic in the oom prevention code.

 Anyway, for now I'd vote for doing what you suggest in the easiest
 possible way even if it saves the system only 50% of the times. It would
 still be a huge improvement upon the current behavior.

Whatever we end up doing, we should not leave much chance of
undercalculating the available memory of we may render Sugar mostly
useless.

This remembers me when we deployed the free-space warning and users
were able to get into situations where they could not use Sugar
because of not enough space but also couldn't remove stuff.

Regards,

Tomeu

 --
   // Bernie Innocenti - http://codewiz.org/
  \X/  Sugar Labs       - http://sugarlabs.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] Review of patch submitted by Martin for bug #2087

2010-09-06 Thread Tomeu Vizoso

On Sat, Sep 4, 2010 at 22:20, Aleksey Lim alsr...@member.fsf.org wrote:
 On Sat, Sep 04, 2010 at 05:13:03PM +0200, Sascha Silbe wrote:
 Excerpts from Kandarp Kaushik's message of Sat Sep 04 16:16:57 +0200 2010:

 [data/sugar.schemas.in]
  +      locale name=C
  +        shortProtected Activities Bundle Indentifiers/short

 Typo. Also a bit hard to understand. Something along the lines of
 Bundle IDs of protected activities might be better.

  +        longUsers will not be allowed to erase these
  +        activities through the list view./long

 [src/jarabe/desktop/activitieslist.py]
  +        if activity_info.is_user_activity() and \
  +            not registry.is_activity_protected(self._bundle_id):
  +                menu_item = MenuItem(_('Erase'), 'list-remove')
  +                menu_item.connect('activate', self.__erase_activate_cb)
  +                self.menu.append(menu_item)
  +                menu_item.show()
  +
  +                if not os.access(activity_info.get_path(), os.W_OK):
  +                    menu_item.props.sensitive = False

 This is getting convoluted. Please factor it out and turn your condition
 into one or several guards [1]. E.g.:

     def _add_erase_option(self, activity_info):
         if not activity_info.is_user_activity():
             return
         if registry.is_activity_protected(self._bundle_id):
             return
         # show menu item etc.

 A suitable docstring is left as an exercise for the reader. ;)


 [src/jarabe/model/bundleregistry.py]
  +        client = gconf.client_get_default()
  +        self._protected_activities =
  client.get_list('/desktop/sugar/protected_activities',
  +                                                      gconf.VALUE_STRING)

 I have a feeling this will break badly if the GConf value is not set.
 See #1147 [2] for a similar case.

 I've found that there is no way to call has() method(all sugar code
 calls get_* methods w/o any checks). If everything is installed, we
 will get key value in any case (default from shcheme), but if
 installation is inproper... I've managed to coredump python for unknow
 keys.

This is really bad and should be fixed inside GConf (though I think
anyway Sugar should be able to deal with incorrect gconf values). That
said, it may be more practical to deal with this problem when we move
to GSettigns/dconf, though that really depends on how many resources
are put into this issue.

Regards,

Tomeu

 And please don't indent this much for a continuation. Personally I'd use
 regular indentation (i.e. four spaces); maybe Tomeu can state his
 preference so we can agree on some guideline.


 PS: Please use git-send-email or some equivalent method of sending
     patches. Your message has had at least one line of the patch
     wrapped; I would have been unable to try out the patch (because
     it wouldn't apply).

 Sascha

 [1] http://en.wikipedia.org/wiki/Guard_(computing)
 [2] https://bugs.sugarlabs.org/ticket/1147
 --
 http://sascha.silbe.org/
 http://www.infra-silbe.de/



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


 --
 Aleksey
 ___
 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] Alt + Tab issue on sugar-emulator

2010-09-06 Thread Tomeu Vizoso

On Sun, Sep 5, 2010 at 21:31, Sascha Silbe
sascha-ml-reply-to-201...@silbe.org wrote:
 Excerpts from Dipankar Patro's message of Sun Sep 05 20:34:55 +0200 2010:

 I was unable to reproduce the bug because the 'Alt + Tab' function doesn't
 work in Sugar on Ubuntu (Neither in emulator nor in Sugar-Session).

 That's probably due to the same bug I've hit on Debian and Bernie before
 me on Fedora 11.

Also note that Xephyr has been almost fully rewritten lately and is
now kind-of-maintained again. So may make sense to just update to a
recent version.

Regards,

Tomeu

 He wrote a patch [1] for metacity that fixes it.
 ISTR Bernie saying something about some other component (X server?)
 being broken and this being just a workaround. Since I don't know any
 details and don't quite understand the change, I haven't filed a bug
 report at Debian yet. I probably should have reported it and let the
 maintainer sort out who actually is to blame. They could at least
 ship the patch for the time being. So feel free to open a ticket on
 Debian.

 The problem with sugar-emulator:
 Somehow the native X sessions' priority is higher then Xephyr's. So even if
 the function for 'Alt+Tab' is coded into Sugar. The emulator (on Xephyr)
 still won't be able to catch that.

 If Xephyr has a global keyboard grab, it will get any keyboard event,
 including Alt-Tab (and anything else your window manager might catch
 otherwise). You can toggle the global keyboard and mouse grab by
 pressing Ctrl+Shift, like it tells you in the Xephyr title bar.
 VNC acquires a global keyboard grab iff running in full screen mode.

 Aleksey suggested we have to disable the 'Alt+Tab' combination in
 Sugar-Emulator.

 What do you mean?

 Sascha

 [1] http://sascha.silbe.org/patches/metacity-ungrab-keybindings.patch
 --
 http://sascha.silbe.org/
 http://www.infra-silbe.de/

 ___
 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] requesting reviews

2010-09-06 Thread Tomeu Vizoso

Hi,

please don't submit the same patch for review to both trac and the
mailing list, otherwise the review discussion bifurcates.

Thanks,

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

Re: [Sugar-devel] Enhancing Sugar to support multiple users

2010-09-06 Thread Marco Pesenti Gritti

On Mon, Sep 6, 2010 at 9:14 AM, Tomeu Vizoso to...@sugarlabs.org wrote:
 I don't think you can give Sugar an accountname as a startup
 parameter, so there's at least something to change.

 When you start Sugar, you are already in an user account, so you don't
 really need to give it an username.

 What is going to allow the user to choose an account with which to log
 in is a display manager and you have several implementations to choose
 from. All should work fine with Sugar.

Hi,

the display manager look and feel should integrate well with the rest
of the UI. We could pick a suggested dm and provide an upstream theme
for it.

Not sure how account name and sugar nick name should interact. Ideally
they would be the same I think, but then you can't change the name
easily.

Finally account management is going to be tricky because it requires
privileges and deployment requirements may vary.

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

Re: [Sugar-devel] Enhancing Sugar to support multiple users

2010-09-06 Thread Marco Pesenti Gritti

On Mon, Sep 6, 2010 at 10:05 AM, Marco Pesenti Gritti ma...@marcopg.org wrote:
 Not sure how account name and sugar nick name should interact. Ideally
 they would be the same I think, but then you can't change the name
 easily.

A possible approach might be sugar nick name == account full name. I
think at least gdm has a way to show full name instead of user name.

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

60 matches

Mail list logo