Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#sugar-meeting, 2011-06-19

 « Previous day | Index | Today | Next day »     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
00:35 cjl_afk is now known as cjl
06:22 cjl has quit IRC
07:32 yama has quit IRC
07:38 meeting <meeting!~sugaroid@jita.sugarlabs.org> has joined #sugar-meeting
07:38 zelazny.freenode.net [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
07:39 yama <yama!~yama@203-158-53-204.dyn.iinet.net.au> has joined #sugar-meeting
07:39 yama has quit IRC
07:39 yama <yama!~yama@ubuntu/member/yama> has joined #sugar-meeting
08:32 pbrobinson has quit IRC
08:33 pbrobinson <pbrobinson!~pbrobinso@2001:41d0:2:923e::> has joined #sugar-meeting
08:37 pbrobinson has quit IRC
08:44 pbrobinson <pbrobinson!~pbrobinso@2001:41d0:2:923e::> has joined #sugar-meeting
09:28 tch has left #sugar-meeting
12:01 lucian <lucian!~lucian@78-86-217-168.zone2.bethere.co.uk> has joined #sugar-meeting
13:42 cjl <cjl!~chatzilla@c-98-204-202-184.hsd1.md.comcast.net> has joined #sugar-meeting
13:59 silbe <silbe!~silbe@twin.sascha.silbe.org> has joined #sugar-meeting
14:44 yama silbe: answering your last comment regarding ntp, yes we can use an ntpd. However, a challenge still exists on the logistics side in getting State-specific settings into XOs.
14:45 It's easy for us to have a standard build across all XOs. Having different settings for different shipments is an inventory/logistical burden.
14:47 silbe: the ntp settings will be different according to where the XO will be deployed, so right now we cannot set this easily before the XO gets to the child
14:50 silbe yama: you could modify /etc/ntp.conf from a NetworkManager hook. IIRC you're using an NTP client from within an NM hook already.
14:51 yama silbe: yes, but the ntp server address will still be different depending on where the XO is
14:52 silbe yama: which is why you would modify ntp.conf - to set the current server address.
14:53 yama silbe: wouldn't that still mean that we need to set the address of the ntp server in advance?
14:53 alsroot yama: whats the problem to point all XO to school server?
14:53 yama alsroot: what school server? :)
14:53 alsroot and treat this problem only on the server
14:53 silbe yama: OpenNTPd can even include separate config files, so you could write just the server address to some file in e.g. /var/lib/ntp
14:53 yama alsroot: no school servers exist
14:54 alsroot yama: you doesn't exist by the deployment design?
14:54 s/you/you mean/
14:54 silbe yama: it only needs to be known whenever it is available. Just stop/restart OpenNTPd accordingly.
14:55 yama silbe: I don't understand how that solves the problem. We'd still need to put the appropriate ntp address in. That address is not the same across the country.
14:55 alsroot: we don't use school servers at this point in time. Only a few are out there.
14:55 silbe yama: sure. But you have the same problem already when using an NTP client from within an NM hook. How did you solve it there?
14:55 lucian_ <lucian_!~lucian@78-86-217-168.zone2.bethere.co.uk> has joined #sugar-meeting
14:57 yama silbe: we haven't yet. We're working on an automagic configuration script that can be run from a USB stick. We're extending the Customisation Stick code for that.
14:58 silbe: the teacher will plug the USB stick in and turn on the XO, the XO will get the settings from a config file on the stick.
14:59 silbe: but I was just thinking, we could just put all the ntp server addresses that we know of into /etc/ntp.conf. The XO would check all of them but only one would work.
15:02 silbe: we are doing some cool stuff with this: https://dev.laptop.org.au/projects/xo-au-usb/wiki
15:09 silbe yama: ah, I see.
15:09 yama: Adding all addresses will add some network traffic, but sounds like a good interim solution.
15:10 yama: will any of the XOs ever roam between networks that need different NTP servers?
15:10 yama silbe: no, they won't.
15:11 silbe yama: ok, then the customisation stick could just modify /etc/ntp.conf once you have a way of determining the NTP server to use.
15:15 yama silbe: yep, that's the plan
15:45 garycmartin <garycmartin!~garycmart@92.26.176.52> has joined #sugar-meeting
16:01 garycmartin lurks in case anyone is here for a design meeting.
16:05 lucian_ has quit IRC
16:16 silbe garycmartin: I'm here for the Design Team meeting, but I don't see Christian or Walter yet...
16:18 garycmartin silbe: Hi, yea have been lurking for half an hour or so but no sign of anyone else.
16:19 silbe garycmartin: we could chat a bit about the ~/Documents folder patch and a related topic: Showing remote objects (XS, other XOs) in the Journal.
16:21 garycmartin silbe: and showing them in the ObjectChooser...
16:23 silbe garycmartin: Ideally that too, but the screen real estate in the Object Chooser is even more limited than in the Journal...
16:25 garycmartin silbe: re your email, Walter did win me over that only revealing the ~/Documents if the user has created such a folder was a reasonable approach. Deployments can also make a call on shipping the feature as default or not when they make their builds (ones that don't ship Sugar + Gnome have a much lesser need for it).
16:25 silbe garycmartin: in the long run (with desktop effects in place to help with the context switches) we should probably do a selection mode in the Journal instead of popping up a dialog...
16:26 garycmartin: nice. So we're good to go for the ~/Documents patch? Are the any design issues left, e.g. icons?
16:27 garycmartin silbe:  Seeing a USB memory stick in Object Chooser seems to work nicely these days, though more than a handful of device icons there might get a little too much.
16:28 cjl is now known as cjl_afk
16:29 garycmartin silbe: I don't think I've seen the ~/Documents patch in action at all. Just read Walters description of it. Are there screenshots of it up on the wiki?
16:30 silbe garycmartin: good question. I haven't seen any screenshot yet either.
16:31 garycmartin silbe: Walter also asked/suggested if gconf should be used to control what locations to reveal (~/Documents being the default). This would allow others to further customise a build if needed.
16:32 (e.g. gconf + existence of that directory would reveal its UI)
16:34 silbe: have you looked through Walter's patch? Is it flexible enough for revealing other locations, or is it hard coded for ~/Documents?
16:35 digs through email, thinks he might have tidied up Walters original icon...
16:37 silbe: yep found it. We exchanged a few emails about if we wanted to stick with his original folder metaphor.
16:37 silbe: Did you see it? I can upload to the wiki.
16:40 silbe garycmartin: the patch shows just the XDG documents folder (nothing else), but we can easily modify it to show other locations. Or maybe do some gvfs magic to show the other locations. The interesting part is the design, not the code.
16:40 garycmartin: uploading to the wiki would be appreciated, esp. if the design is final (=> documentation).
16:42 garycmartin: is it the icon from your mail on 2011-05-16 20:17?
16:42 (Message-ID: DDFFF45D-F3C8-46C1-B51E-E63B3564B06A@gmail.com)
16:42 garycmartin http://wiki.sugarlabs.org/go/F[…]cuments-large.png
16:43 silbe thanks!
16:43 garycmartin silbe: I just had a moments indecision. I made both the folder and the document parts of the icon use the users fill/stroke...
16:45 silbe: Should either perhaps be in black/white. i.e black/white for the folder would help indicate it was not the same type of location users Journal.
16:46 silbe garycmartin: Not sure about it. We show mounted devices fully coloured as well...
16:47 garycmartin silbe: or you could argue that the folder should be in user fill/stroke colours, but the document be black/white to indicate the location is yours, but the objects in it will often be 'un-owned'.
16:50 wonders if you have write permission to a folder/device than it can be thought of as yours, not that we've used that idea before.
16:51 silbe garycmartin: that assumption would break for remote objects (something several of us are working on)
16:53 garycmartin silbe: remote objects being remote fs mounts? or something else (special services, say a wrapper for ASLO so you can download activities directly in Sugar rather than via a web browser)
16:54 silbe garycmartin: Of course, even for locally attached mount point showing them as "ours" can be a bit of a stretch (it might be a friends stick they brought over to show us some of their content), but I don't think we can really do any better...
16:56 garycmartin: There are various implementations under discussion (NFS/CIFS/Samba, special-purpose network file system, WebDAV mounted as a file system, direct WebDAV access in Journal via GVFS, ...). What they all have in common is that they show objects located on a different computer, potentially including objects created by other users.
16:59 garycmartin silbe: I'd love to see the school server icon coloured but fill and scroke colours based on it's identity, and the same for remote server entities.
16:59 s/but/by/
17:00 silbe garycmartin: Interesting idea. If we have an FQDN for the server, we could hash it to derive a colour, similar to what we do with SSIDs for APs.
17:01 garycmartin silbe: yep!
17:01 silbe garycmartin: This wouldn't work if the XS has just "schoolserver" as name and no domain configured, but maybe that just gives more incentive to admins to properly configure the server. ;)
17:04 yama has quit IRC
17:05 garycmartin silbe: you mentioned "showing other XOs" in the Journal, care to elaborate? Is this along the vague lines of some of cscotts Journal2 sharing ideas?
17:05 yama <yama!~yama@203-158-53-204.dyn.iinet.net.au> has joined #sugar-meeting
17:05 yama has quit IRC
17:05 yama <yama!~yama@ubuntu/member/yama> has joined #sugar-meeting
17:09 silbe garycmartin: there's nothing concrete yet. There's quite a bit of interest in these topics. We (=at least tch and me) are currently exploring some potential technical solutions. I gather showing objects on a shared server is a priority for OLPC-AU (hi yama!).
17:10 garycmartin, yama: One issue we haven't looked at yet is how to discover the resource.
17:10 garycmartin silbe: +1 to showing objects on a shared server, but this could be as simple as the age old solution of a public folder on an available server.
17:12 silbe obvious options are always showing preconfigured resources and a "Mount network location" style UI element somewhere.
17:12 garycmartin silbe: so the current school server solution doesn't provide for a public drop box type feature? You have to jump through moodle hoops?
17:12 silbe I don't really like either of them...
17:14 garycmartin: at least in AU, most schools don't have an XS. Those that do have a Moodle instance seem not to like it (and definitely won't have any Sugar-specific customisations or extensions). Or at least that's my understanding so far.
17:14 garycmartin silbe: perhaps some trick as per the schoolserver where a standard named host is looked for.
17:15 silbe garycmartin: that would essentially be the preconfigured resource option
17:15 garycmartin silbe: If it's deployment focused, perhaps gconf could be used to store a specific host name to look for, with (in the future) a CP module that can edit and add to the selection.
17:16 silbe garycmartin: it works fine for an XS-like set-up, but not for accessing other servers (think showcase.sugarlabs.org).
17:17 garycmartin silbe: ...a little like the current CP module for network that has a field for the schoolserver (could do with quite some tidy up).
17:17 silbe garycmartin: the focus is on what the deployments need now, i.e. a school server like set-up. But if we can make it work for other use cases, it would be even better.
17:19 garycmartin silbe: but if you can have multiple entries can't others be provided by default (deployments can remove as required). Not something I think the schoolserver/jabberserver UI code currently allows access to.
17:20 silbe gnome-user-share sounds interesting: gnome-user-share is a small package that allows easy user-level file sharing via WebDAV or ObexFTP. The shared files are announced on the network by Avahi.
17:20 (for accessing other XOs or even non-Sugar systems)
17:20 garycmartin: sorry, you lost me...
17:21 garycmartin silbe: Avahi sounds good for local services at least.
17:22 silbe garycmartin: a CP section sounds reasonable for more or less fixed resource like a school server or showcase.sugarlabs.org.
17:23 garycmartin: I wonder how we could support the accessing-other-XOs use case in the UI. Showing each XO in the Volumes tool bar in the Journal wouldn't scale.
17:23 garycmartin silbe: I'll trying again ;) so if we allowed gconf based values for multiple host names to look for, we could have a range of locations checked for and revealed if found.
17:24 tch <tch!~tch@228.93.23.190.res.adsl.dyn.click.com.py> has joined #sugar-meeting
17:25 silbe garycmartin: We could show those volumes in the Neighbourhood, but in that case we'd probably want to associate them with users instead of showing them on their own. And I don't think that association will work in the general case (though we probably could make it work for some)...
17:25 garycmartin silbe: re accessing others XOs, could you clarify a little. It this free reign to access any Journal entry, or something else (e.g. just entries flagged as public)?
17:27 silbe garycmartin: so you'd like us to reveal the button when the resource can be successfully connected to and check in the background for that? (Implications: a) we need to do periodic checks and b) the Volume toolbar can appear any time)
17:29 garycmartin silbe: bouncing back ;) so you'd like users to explicitly 'connect to' extra resources that show up in the neighbourhood view (be they Avahi discovered or some default host attempt)?
17:29 silbe garycmartin: still open for discussion. Personally I'd prefer only explicitly marked entries to be published, but AFAIK deployments don't care as much. It's definitely something we need to work on (i.e. add UI to choose which entries to export / not to export), but for the first version an all-or-nothing approach might be good enough.
17:32 garycmartin silbe: my worry for all or nothing, is that deployments may choose all, if access is then also on by default, harvesting childrens journal entries becomes a very real danger to those so inclined, photos being the more worrying case.
17:32 silbe garycmartin: that would be the idea, yes. But anything else that scales to hundreds of Journals / shared folders would be fine as well. While we need to do the mount operation on the implementation side, there's no requirement to expose it that way in the UI.
17:34 garycmartin: that's exactly my worry as well. Maybe a reasonable interim solution is showing just those marked as favourite. It would be an abuse of the favourite star, but at least we already have UI for it.
17:35 We could also use a tag "export". But while there's UI for that, too, this option is too obscure.
17:35 *I'm afraid this option is
17:36 garycmartin silbe: +1 on showing available shared resources in neighbourhood view, and then mounting them on explicit request by the user (clicking the icon, or hovering over the resource, seeing the short name/description and selecting 'connnect'). I think we would need to switch to the Journal, select that resource, and have a spinner in the main canvas while object info is accessed (or a failure alert raised).
17:39 silbe garycmartin: ok. So how do we present them in the Neighbourhood a) in case we can associate a buddy with the resource and b) in case we can't?
17:41 the reason for inability to associate with a buddy can be a) non-Sugar user, b) no user at all (shared folder on a server) and maybe c) technical difficulties
17:41 garycmartin silbe: public/private needs an appropriate UI to expose that feature as it's a major feature. Perhaps the ongoing multi object selection will provide us some pathways to leverage.
17:46 silbe: b) shared folder on a server; should be presented as a (possibly new) object. Do we show the server (with possibly several shared folders in its palette), or do we break out each shared folder into its own object? Do you have any example use cases (do folks want to share one, two three folders, or more)?
17:46 silbe garycmartin: FWIW several systems I've worked with have three different levels: public, friends (resp. partner) only ("private" in Windows Mobile), no sharing ("confidential").
17:47 garycmartin: I could imagine some folks wanted to use a different folder for each class. Since we don't show hierarchies in the Journal, they'd need to be exposed as different folders in the Neighbourhood somehow.
17:49 garycmartin silbe: c) is raising an error dialogue when a user tries to connect and it fails (given that the technical difficulties don't prevent discovery in the first place, in which the object would never be shown, likely case is a user/network going out of range or switching off).
17:53 silbe garycmartin: c) isn't about an error connecting to the resource, but rather about being unable to match the resource with a Buddy for unknown reasons. There's probably no way for us to distinguish between b) and c).
18:02 garycmartin silbe: a discoverable shared resource, not matched to a specific buddy, is surly a new object type (if we can/want to support, e.g. a printer, a NAS)? I like the idea of supporting standard resources in the neighbourhood (obviously needing new icons, palette options, and potentially new dialogues for their UI needs).
18:03 silbe garycmartin: it could also be a user we don't have a Telepathy connection to.
18:09 garycmartin silbe: Services provided by Sugar buddies is perhaps more controllable task to work on (buddy makes public N objects from their Journal, their buddy icon palette provides an entry to 'Connect to shared Journal' which would switch to Journal as it made the attempt). Question, would dragging one of your own Journal entries into a buddy volume icon transfer it (as if you were connected to a remote volume), or invoke the send to friend UI where the
18:09 remote buddy would need to accept the transfer?
18:09 silbe: re "don't have a Telepathy connection to", what type of user would that be?
18:28 silbe garycmartin: it could be a user we share a network connection with, but who's using a different Jabber server. Or same server, but not visible to us.
18:31 garycmartin: interesting question re. the drag&drop. I'd skip that question for now and simple make shared Journals read-only (and not switch to file transfer automatically), whereas servers would be configured to allow write access (the whole point of their existence).
18:36 garycmartin silbe: argh! sorry, distracted by domestic duties. I'll post the logs to the design meeting (lots of interesting threads here).
18:36 silbe: Apologies, have to dash, thanks for the chat. Interesting topic.
18:47 silbe garycmartin: thanks too. Have a nice evening!
19:08 garycmartin has quit IRC
21:44 silbe has quit IRC
22:01 yama` <yama`!~yama@124-149-121-90.dyn.iinet.net.au> has joined #sugar-meeting
22:01 yama` has quit IRC
22:01 yama` <yama`!~yama@ubuntu/member/yama> has joined #sugar-meeting
22:04 yama has quit IRC
22:27 tch has quit IRC
23:50 lucian has quit IRC

 « Previous day | Index | Today | Next day »     Channels | Search | Join

Powered by ilbot/Modified.
Webmaster