date:20090703

On Thu, Jul 2, 2009 at 06:08, Sascha
Silbesascha-ml-ui-sugar-de...@silbe.org wrote:
 On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote:

 in this week we want to talk about the Journal and datastore [1]
 improvements planned for 0.86.

 I really hope to make it (my GSoC work depends on it - there's a lot of
 stuff to talk about and some decisions to make) but am not sure I can
 (especially given how flakey internet access is ATM). Would be great to at
 least be able to read the meeting logs afterwards (as usual).

 [1] contains my thoughts on a VCS based datastore rewrite - a bit fleshed
 out now, but still not finished. The most important part for now is that I'd
 like to change the find() API call to take two parameters instead of one.
 Right now, the single parameter is a mixture of a query (giving key-value
 pairs that entries must match to be returned) and of output options (sorting
 order etc.). As we need to change API for version support anyway I'd like to
 seize that opportunity to fix this mess (no offense intended).

 While the document currently mentions the index backend quite often I might
 actually skip it at first and use only the database backend instead. Xapian
 (an Information Retrieval system used by the current datastore to provide
 simple metadata search) is very interesting and could be quite useful for a
 future FindMyData activity - but IMO with a new API focussing on
 probabilistic information retrieval, including spell checking and partial
 queries (Xapian terms seem to correlate quite well with Sugar tags,
 BTW). The basic attribute search stuff currently used is IMO best done using
 a database, not an IR system.

 The document is largely a braindump, not a design document yet. So please
 overlook the rough edges and the fact that I'm proposing a full rewrite - I
 might end up recycling a large part of the current code base, but thinking
 of it as a new thing helps me see things more clearly.


 [1]
 http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html

There's lots of interesting stuff in there, will ask some questions
today in a separate thread.

Regards,

Tomeu

 CU Sascha

 --
 http://sascha.silbe.org/
 http://www.infra-silbe.de/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iQEcBAEBAgAGBQJKTDKsAAoJELpz82VMF3Da9j4IAKPAS8n/UAOn2Anqoq+RqtHF
 Ez1g5CUG+3q4yS5bwpwBGRWu1pEvT+GIrr+lXLsloSGtidApfopIhVIOmNR3wGHn
 F3cPLPjcsdoosqWAMdEC+TWpXAwNlLS5mSk4T8o/podUTqnaBnRT7W09DUaPF2L9
 2oAfme73dyHpFplf9qARIZeWqFGEiDDN3H9tN6yQxY0laozLnTTwDn8OCqIzHcqR
 VitMO8s979xO7MYsJzLC+4dXwcADKlPQQOqObcJyxfR7zb29ShkSl/W7Tv+AuAiD
 S23qscIoT6/BAcxRdAlrczvxJtc500VwikzRDy1tuFVKHjpJxdOYROuFOqhRg8Q=
 =sRau
 -END PGP SIGNATURE-

 ___
 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] Gecko for Win32, pyjamas-desktop, python-hulahop

2009-07-03 Thread Luke Kenneth Casson Leighton

folks, hi, just wanted to mention a couple of things that i found.

1) you'll be pleased to know that i managed to hack pyjamas-desktop
into submission to use python-hulahop, at europython over the last
couple of days.  i managed to get window event listeners going,
element listeners _and_ XMLHTTPRequest async callbacks - all
python-based.  none of which would be possible without
hulahop.WebView.  so - thank you.

2) i found a page yesterday of a GSoc 2009 student who was proposing
to port hulahop to webkit.  i put on the talk page that of course
because pywebkitgtk now has python bindings to the DOM that most of
the work is now done and so his task will be made much easier.  that's
if GSoc 2009 is still going.  or if his proposal was accepted.
anyway, just mentioning it.

3) the next step is of course to have python-hulahop running on win32,
alongside python-xpcom, yippee, won't that be fun.  so, looking around
for xulrunner for win32, i find that the olpc page says Install
Gecko: TODO ha :)  so anyway i found this:
http://www.novell.com/coolsolutions/feature/14918.html which may
contain the stuff that's needed. i.e. GRE (gecko runtime environment).
 i mean, after all, firefox compiles for win32 duh so it should be
perfectly possible to get XUL and python-xpcom, right? h :)

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

Re: [Sugar-devel] netbook as terminology

2009-07-03 Thread Martin Langhoff

On Fri, Jul 3, 2009 at 12:26 PM, Bill Kerrbillk...@gmail.com wrote:
 Also noticed recently that NN reacted against the netbook terminology:
 http://billkerr2.blogspot.com/2009/07/xo-is-not-netbook.html
 Negroponte: Kids in Ethiopia don't have the internet in a nearby cloud ...

I like the phrase. We just found the perfect icon for the XS ;-)

cheers,


m
-- 
 martin.langh...@gmail.com
 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] Gecko for Win32, pyjamas-desktop, python-hulahop

2009-07-03 Thread Lucian Branescu

2) That was my backup proposal in fact, and I ended up getting
accepted with this one http://wiki.sugarlabs.org/go/Webified

I'd still like to make browse Browse able to use webkit (and
preferably to be able to switch between webkit and gecko), but that's
for after GSoC. I'll probably love that wrapper script :)

2009/7/3 Luke Kenneth Casson Leighton l...@lkcl.net:
 folks, hi, just wanted to mention a couple of things that i found.

 1) you'll be pleased to know that i managed to hack pyjamas-desktop
 into submission to use python-hulahop, at europython over the last
 couple of days.  i managed to get window event listeners going,
 element listeners _and_ XMLHTTPRequest async callbacks - all
 python-based.  none of which would be possible without
 hulahop.WebView.  so - thank you.

 2) i found a page yesterday of a GSoc 2009 student who was proposing
 to port hulahop to webkit.  i put on the talk page that of course
 because pywebkitgtk now has python bindings to the DOM that most of
 the work is now done and so his task will be made much easier.  that's
 if GSoc 2009 is still going.  or if his proposal was accepted.
 anyway, just mentioning it.

 3) the next step is of course to have python-hulahop running on win32,
 alongside python-xpcom, yippee, won't that be fun.  so, looking around
 for xulrunner for win32, i find that the olpc page says Install
 Gecko: TODO ha :)  so anyway i found this:
 http://www.novell.com/coolsolutions/feature/14918.html which may
 contain the stuff that's needed. i.e. GRE (gecko runtime environment).
  i mean, after all, firefox compiles for win32 duh so it should be
 perfectly possible to get XUL and python-xpcom, right? h :)

 l.
 ___
 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] Gecko for Win32, pyjamas-desktop, python-hulahop

2009-07-03 Thread Luke Kenneth Casson Leighton

On 7/3/09, Lucian Branescu lucian.brane...@gmail.com wrote:
 2) That was my backup proposal in fact, and I ended up getting
  accepted with this one http://wiki.sugarlabs.org/go/Webified

 ooo.  ah.  take a look at pygtkweb (in pyjamas) and note that luis
pamirez solved the import pythonmodule problem by using JSONRPC
exactly as you outline.

however what he did was provide a way to run pygtk apps in a web
browser (unmodified) and i'm not quite sure that that's the same thing
that you're proposing in Webified but i'm sure there's quite a lot
of crossover.

luis only had about 8 weeks so he only got up to rangewidgets.py pygtk
example, which is still a heck of a long way.

but - the principle, it shows that it's perfectly possible to port a
python-based Widget GUI API to run in web browsers, using the pyjamas
compiler.

much of luis' work was to improve the pyjs compiler at the time: if
what you are proposing is to port the Sugar GUI API to the web then,
because luis already created browser.py and also because pyjs compiler
is much more mature, you should get a heck of a long way further.

plus, because Sugar GUI still relies on pygtk in a lot of places you
can leverage his work.

... that's if i have translated your proposal correctly as being make
Sugar apps run (unmodified) in web browsers.

if you decide not to go generic web browser and instead decide to go
browser engine e.g. pywebkitgtk or e.g.
gecko/xul/python-xpcom/hulahop then you should definitely look at
pyjamas-desktop and _still_ look at making luis pygtkweb work run in
pyjamas-desktop!

yes, i know - that's a port of gtk to pyjamas where pyjamas runs on
top of gtk.  crazy idea but it's because pyjamas API is an abstraction
layer where one of the lower layers _happens_ to be gtk at the moment.

so, lots of options and opportunities.

  I'd still like to make browse Browse able to use webkit (and
  preferably to be able to switch between webkit and gecko), but that's
  for after GSoC. I'll probably love that wrapper script :)

 yehh - take a look in pyjamas at pyjd/pywebkitgtk.py and also in
pyjd/hula.py they are near-identical.  a wrapper (submitted as a patch
to pywebkitgtk, #13) wraps the [stupid] glib/gobject naming convention
making it look like proper W3C DOM functions and thus near-identical
to xpcom.

 so in that way you are independent of the underlying DOM technology.
unfortunately, python-khtml is broken (c++ RTTI related bug and a bug
in kde's twine python-c++ auto-generator) but if it wasn't it could be
added as the third option.  macos pyobjc is the fourth option to be
considered.

in this way, you can see that if Sugar apps are based on DOM
technology (indirectly) you have maaany more options.  and if you look
at the list of dependencies to e.g. get python-hulahop compiled for
Win32, you _really_ want to open up the options much much more, by
making Sugar apps run in web browsers and on web engine technology,
rather than try to hit heads against brick walls compiling xulrunner,
python-xpcom 40mb downloads on windows ICK! :)

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

Re: [Sugar-devel] Gecko for Win32, pyjamas-desktop, python-hulahop

2009-07-03 Thread Lucian Branescu

I'm afraid you misread my proposal. I'm making a SSB for sugar, akin
to Fluid (http://fluidapp.com) and Mozilla Prism. This would allow web
applications to work nicely in Sugar as separate activities
(applications). Stuff like userstyles, userscripts,
bookmarklets-as-buttons and javascript-dbus can greatly enhance the
Sugar integration, making web apps seem even more like native
activities. In fact I should stop using 'would', because creating SSBs
works! Userstyles and userscripts will come soon.

In general, people are trying to get web stuff to work nicely in Sugar
(see 
http://blog.tomeuvizoso.net/2009/05/progress-on-sugar-activities-with-swf.html
and http://karmaproject.wordpress.com/), not the other way around.
Mostly because loads more people know flash/html+js than Python.

Of course, efforts going the other way are more than welcome, but they
have less impact in the short term.

2009/7/3 Luke Kenneth Casson Leighton l...@lkcl.net:
 On 7/3/09, Lucian Branescu lucian.brane...@gmail.com wrote:
 2) That was my backup proposal in fact, and I ended up getting
  accepted with this one http://wiki.sugarlabs.org/go/Webified

  ooo.  ah.  take a look at pygtkweb (in pyjamas) and note that luis
 pamirez solved the import pythonmodule problem by using JSONRPC
 exactly as you outline.

 however what he did was provide a way to run pygtk apps in a web
 browser (unmodified) and i'm not quite sure that that's the same thing
 that you're proposing in Webified but i'm sure there's quite a lot
 of crossover.

 luis only had about 8 weeks so he only got up to rangewidgets.py pygtk
 example, which is still a heck of a long way.

 but - the principle, it shows that it's perfectly possible to port a
 python-based Widget GUI API to run in web browsers, using the pyjamas
 compiler.

 much of luis' work was to improve the pyjs compiler at the time: if
 what you are proposing is to port the Sugar GUI API to the web then,
 because luis already created browser.py and also because pyjs compiler
 is much more mature, you should get a heck of a long way further.

 plus, because Sugar GUI still relies on pygtk in a lot of places you
 can leverage his work.

 ... that's if i have translated your proposal correctly as being make
 Sugar apps run (unmodified) in web browsers.

 if you decide not to go generic web browser and instead decide to go
 browser engine e.g. pywebkitgtk or e.g.
 gecko/xul/python-xpcom/hulahop then you should definitely look at
 pyjamas-desktop and _still_ look at making luis pygtkweb work run in
 pyjamas-desktop!

 yes, i know - that's a port of gtk to pyjamas where pyjamas runs on
 top of gtk.  crazy idea but it's because pyjamas API is an abstraction
 layer where one of the lower layers _happens_ to be gtk at the moment.

 so, lots of options and opportunities.

  I'd still like to make browse Browse able to use webkit (and
  preferably to be able to switch between webkit and gecko), but that's
  for after GSoC. I'll probably love that wrapper script :)

  yehh - take a look in pyjamas at pyjd/pywebkitgtk.py and also in
 pyjd/hula.py they are near-identical.  a wrapper (submitted as a patch
 to pywebkitgtk, #13) wraps the [stupid] glib/gobject naming convention
 making it look like proper W3C DOM functions and thus near-identical
 to xpcom.

  so in that way you are independent of the underlying DOM technology.
 unfortunately, python-khtml is broken (c++ RTTI related bug and a bug
 in kde's twine python-c++ auto-generator) but if it wasn't it could be
 added as the third option.  macos pyobjc is the fourth option to be
 considered.

 in this way, you can see that if Sugar apps are based on DOM
 technology (indirectly) you have maaany more options.  and if you look
 at the list of dependencies to e.g. get python-hulahop compiled for
 Win32, you _really_ want to open up the options much much more, by
 making Sugar apps run in web browsers and on web engine technology,
 rather than try to hit heads against brick walls compiling xulrunner,
 python-xpcom 40mb downloads on windows ICK! :)

 l.

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

Re: [Sugar-devel] Questions about GConf and ORBit.

2009/7/3 Michael Stone mich...@laptop.org:
 Dear sugar-devel, (and Tomeu and Simon in particular),

 I decided to spend a few hours this evening investigating the state of
 rainbow+sugar.

 My current results are based on tests performed in a Debian Squeeze chroot
 constructed according to the procedures I wrote down at

  http://wiki.sugarlabs.org/go/Development_Team/Chroot

 Today, these procedures wound up installing

  education-desktop-sugar 0.837
  python-sugar-0.84 0.84.1-1
  python-sugar-toolkit-0.84 0.84.4-3

 and a variety of other things.

 I then installed rainbow according to the source code installation 
 instructions
 at

  http://wiki.laptop.org/go/Rainbow/Installation_Instructions

 and installed the sugar and sugar-toolkit patches:

  curl 
 'http://dev.laptop.org/git/users/mstone/sugar/patch/?id=71df9fadd59ea5cc08a414f5d25a0135395533e5'
  | patch /usr/share/pyshared/jarabe/view/service.py
  curl 
 'http://dev.laptop.org/git/users/mstone/sugar-toolkit/patch/?id=a65c8d2148ba5028437114049027e594238f2ed8'
  | patch /usr/share/pyshared/sugar/activity/activityfactory.py

 that Sascha and I wrote a few months ago.

 Then I ran

  touch /etc/olpc-security

 to tell sugar to try to use rainbow.

 Then, after commenting out a few lines in /usr/bin/rainbow-sugarize, (notably,
 handling of XAUTHORITY, .sugar/config, and TMPDIR), I ran into the following
 persistent activity-launch failure:

 (See attached log for full details; the interesting bit is excerpted below.)

 ---
 ...
 about to execve
 argv: ['sugar-activity', 'pippy_app.Chat', '-b', 'org.laptop.Chat', '-a', 
 '5fb7b60ee4635e7e67161464dab772656c660274']
 env: {'SUGAR_BUNDLE_PATH': '/usr/share/sugar/activities/Chat.activity', 
 'SUGAR_SCALING': '100', 'LM_DEBUG': 'net', 'LOGNAME': 'sugar', 'USER': 
 '10012', 'PATH': 
 '/usr/share/sugar/activities/Chat.activity/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games',
  'HOME': '/var/spool/rainbow/2/uid_to_home_dir/10012', 'DISPLAY': 
 'localhost:1', 'LANG': 'en_US.UTF-8', 'TERM': 'xterm', 'SHELL': '/bin/bash', 
 'TZ': 'UTC', 'SESSION_MANAGER': 
 'local/heat:@/tmp/.ICE-unix/21077,unix/heat:/tmp/.ICE-unix/21077', 'SHLVL': 
 '2', 'ICEAUTHORITY': 
 '/var/spool/rainbow/2/uid_to_home_dir/10012/.ICEauthority', 'SUDO_USER': 
 'root', 'USERNAME': 'root', 'SUDO_UID': '1000', 'SUGAR_ACTIVITY_ROOT': 
 '/var/spool/rainbow/2/uid_to_home_dir/10012', 'SUGAR_LOGGER_LEVEL': 'debug', 
 'GTK2_RC_FILES': '/usr/share/sugar/data/sugar-100.gtkrc', 'SUGAR_BUNDLE_ID': 
 'org.laptop.Chat', 'DBUS_SESSION_BUS_ADDRESS': 
 'unix:abstract=/tmp/dbus-Yk6Co1qS9e,guid=fce2be94a630405102e085bc4a4d6a08', 
 'SUDO_COMMAND': '/usr/sbin1246589388.964848 DEBUG root: *** Act 
 5fb7b60ee4635e7e67161464dab772656c660274, mesh instance None, scope private
 1246589388.975903 DEBUG root: Creating a jobject.
 Traceback (most recent call last):
  File /usr/bin/sugar-activity, line 21, in module
    main.main()
  File /usr/lib/python2.5/site-packages/sugar/activity/main.py, line 140, in 
 main
    create_activity_instance(activity_constructor, activity_handle)
  File /usr/lib/python2.5/site-packages/sugar/activity/main.py, line 34, in 
 create_activity_instance
    activity = constructor(handle)
  File /usr/share/sugar/activities/Chat.activity/pippy_app.py, line 54, in 
 __init__
    super(Chat, self).__init__(handle)
  File /usr/share/sugar/activities/Chat.activity/activity.py, line 22, in 
 __init__
    super(ViewSourceActivity, self).__init__(handle)
  File /usr/lib/python2.5/site-packages/sugar/activity/activity.py, line 
 556, in __init__
    icon_color = client.get_string('/desktop/sugar/user/color')
 glib.GError: Failed to contact configuration server; some possible causes are 
 that you need to enable TCP/IP networking for ORBit, or you have stale NFS 
 locks due to a system crash. See http://projects.gnome.org/gconf/ for 
 information. (Details -  1: Server ping error: 
 IDL:omg.org/CORBA/COMM_FAILURE:1.0)
 1246589389.150681 DEBUG root: _cleanup_temp_files
 Activity died: pid 21590 condition 256 data 
 5fb7b60ee4635e7e67161464dab772656c660274

 ---

 Based on this traceback and a quick round of Googling, it seems likely to me
 that at least one of gconf or orbit is assuming that human operators have only
 one uid.

 Hence two questions:

  1. Do you know anything about such an assumption?

No, but I don't see that in the logs. What I see is one process trying
and failing to access GConf. Is there a GConf daemon running? Either
using Orbit or D-Bus? If so, what's the mechanism used by clients to
contact the daemon? Maybe an env var is missing?

  2. Are more bleeding-edge versions of Sugar still using gconf-over-orbit?

Sugar is a normal GConf client in this regard. My understanding is
that if it links to the D-Bus client library, it will use D-Bus. Orbit
otherwise.

HTH,

Tomeu

Re: [Sugar-devel] Questions about GConf and ORBit.

2009-07-03 Thread Michael Stone

Tomeu,

Thanks for the prompt reply. 

 Do you know anything about such an assumption?

 No, but I don't see that in the logs. 

True.

 What I see is one process trying and failing to access GConf. 

Agreed. Do you have any advice on how I might extract a better error message
from it?

(Or on what symbols I should breakpoint in gdb so that I can see what's
happening?)

 Is there a GConf daemon running? 

Yes, but it's running under the credentials of the owning user (sugar) rather
than the requesting user. (Hence my suspicions.)

 Either using Orbit or D-Bus?

How can I tell?

 If so, what's the mechanism used by clients to contact the daemon? 

Again, how can I tell?

 Maybe an env var is missing?

Seems eminently plausible. Do you know of any env-vars that gconf-and-deps pay
specific attention to?

 2. Are more bleeding-edge versions of Sugar still using gconf-over-orbit?

 Sugar is a normal GConf client in this regard. My understanding is
 that if it links to the D-Bus client library, it will use D-Bus. Orbit
 otherwise.

Okay, thanks. I guess I'll just have to dig out the source code.

Thanks,

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

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

On 2 Jul 2009, at 14:47, Eben Eliason wrote:
 On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org  
 wrote:
 But in that case we should provide possibility to mark objects that  
 can
 be shared(I guess sharing all local objects by default is not a  
 nice idea).

 Right. This would be essential. There's definitely some thought that
 needs to be done here.

 Scott had an interesting proposal which basically exposed the Journal
 (or some subset of it) as an RSS feed. This was really neat, because
 it meant we could build a UI for someone else's Journal in Sugar,
 populating it with that data, but also that these feeds could be
 shared globally, for anyone with an RSS reader to benefit from. That's
 a really powerful approach in my mind, and there is some starter code
 lying around as a proof of concept already!


+1 to rss feed concept, makes life a lot easier in a heterogeneous  
environment.

I'm still catching up on email so apologies if this has been mentioned  
already. But the UI for marking of entries as sharable does not  
necessarily need to be another Journal user-interface addition** In  
the simplest approach you could just extend the Activity Share with:  
my Neighbourhood control to mark a Journal entry as part of the RRS  
feed. Would need some thought on wording, do you add more levels of  
sharing? Or do you just simplify the Share with: language language  
to Private, Share with: Anyone.

**though I would like entries to visually show their sharing state,  
the buddy column hints at this but should be made explicit

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

Re: [Sugar-devel] Questions about GConf and ORBit.

On Fri, Jul 3, 2009 at 16:06, Michael Stonemich...@laptop.org wrote:
 Tomeu,

 Thanks for the prompt reply.

 Do you know anything about such an assumption?

 No, but I don't see that in the logs.

 True.

 What I see is one process trying and failing to access GConf.

 Agreed. Do you have any advice on how I might extract a better error message
 from it?

Nope :/

 (Or on what symbols I should breakpoint in gdb so that I can see what's
 happening?)

Have never needed to resort to that, but I would look at the GConf
code first, then breakpoint in the interesting funcs.

 Is there a GConf daemon running?

 Yes, but it's running under the credentials of the owning user (sugar) 
 rather
 than the requesting user. (Hence my suspicions.)

Is a good suspicion, maybe something orbit or corba related? Though it
would weird to find such limitation at that level without a mechanism
to workaround it.

The message hints at TCP/IP for orbit, in that case the client and the
server may not even live on the same machine.

 Either using Orbit or D-Bus?

 How can I tell?

See if the server process executable is in /usr and if so, which .deb
is installed.

 If so, what's the mechanism used by clients to contact the daemon?

 Again, how can I tell?

See which .so links the client and if it's in /usr, which .deb is installed.

 Maybe an env var is missing?

 Seems eminently plausible. Do you know of any env-vars that gconf-and-deps pay
 specific attention to?

Nope.

 2. Are more bleeding-edge versions of Sugar still using gconf-over-orbit?

 Sugar is a normal GConf client in this regard. My understanding is
 that if it links to the D-Bus client library, it will use D-Bus. Orbit
 otherwise.

 Okay, thanks. I guess I'll just have to dig out the source code.

Yeah, I think I would do that at this point.

Regards,

Tomeu

 Thanks,

 Michael
 ___
 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] Gecko for Win32, pyjamas-desktop, python-hulahop

2009-07-03 Thread Luke Kenneth Casson Leighton

On 7/3/09, Lucian Branescu lucian.brane...@gmail.com wrote:
 I'm afraid you misread my proposal. I'm making a SSB for sugar, akin
  to Fluid (http://fluidapp.com) and Mozilla Prism. This would allow web
  applications to work nicely in Sugar as separate activities
  (applications).

 ok, so i have yahoo.com on a menu somewhere and click on it and it
appears in a dedicated application not in a web browser but a
dedicated [sugar] app.

 ok - that sounds easy - much easier than what i thought you said :)

 Stuff like userstyles, userscripts,
  bookmarklets-as-buttons and javascript-dbus can greatly enhance the
  Sugar integration, making web apps seem even more like native
  activities. In fact I should stop using 'would', because creating SSBs
  works! Userstyles and userscripts will come soon.

 ah, cool!

 good luck

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

Re: [Sugar-devel] Karma: quadrilaterals + Surf it works!

2009-07-03 Thread Bobby Powers

2009/7/2 Felipe López Toledo zer.subz...@gmail.com:
 Hi Andrés,

 I have tested it (quadrilaterals) under Ubuntu 8.10

I see the same I see on a non html5 enabled browser.
 , you're right, it seems the webkit-gtk isn't updated :S

 I've checked line 49: ctx.fillText ( Erase, 25, 245 );
 I supposse the current webkit doesn't support this instruction

 :(

On FFX 3.5preb4 it works great!
 yes, the problem is that ff in the XO has a poor performance and if you use
 quadrilaterals you will get a serious lag,
 using surf in the XO, it  works really good

This is great news.  I'm having network issues on my laptop, but
hopefully I'll have some time to work on Surf this coming week to make
it more functional (downloads, etc).

Bobby

One little comment: it doesnt recognize concave quadrilaterals properly.
 yes, It was how I solved, not the real code from flash.
 thanks for your comment, I'll fix it.

 felipe
 2009/6/30 Andrés Ambrois andresambr...@gmail.com

 On Tuesday 30 June 2009 03:17:00 pm Felipe López Toledo wrote:
  hi guys
 
  I'm a little upset because during last week I was trying to optimize the
  Quadrilaterals activity:
  http://karma.sugarlabs.org/quadrilaterals/
 
  Lucian recommend me (last week...or before) to try it using Surf,
  I was trying to compile it from source... mmm, no progress
  today Lucian gave me some links:
  the xo bundle: http://dev.laptop.org/~bobbyp/surf/
  also read: http://wiki.laptop.org/go/Browse/WebKit
 
  thanks Lucian
 
  well, if you have a chance please test it,
  it works really good (performance) there is some work to do (stuff
  related
  to css and scale), but it works a lot better than with firefox
 
  :)

 Tried Quadrilaterals with Surf-106 on Jhbuild on Ubuntu Jaunty.

 I see the same I see on a non html5 enabled browser.  The log ends with
 this
 line:

 console message: http://karma.sugarlabs.org/quadrilaterals/js/activity.js
 @49:
 Value undefined does not allow function calls.

 libwebkit on Jaunty is v1.0.1

 On FFX 3.5preb4 it works great! One little comment: it doesnt recognize
 concave quadrilaterals properly.
 --
  -Andrés


 ___
 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] On datastore object IDs

On Thu, Jul 2, 2009 at 19:20, Martin Langhoffmartin.langh...@gmail.com wrote:
 On Thu, Jul 2, 2009 at 6:35 PM, Benjamin M.
 Schwartzbmsch...@fas.harvard.edu wrote:
 We've been talking a lot about how datastore version 3 (?) should be
 structured.  I'd like to propose (purely to initiate discussion) that it
 be structured as follows:

 Slightly OT: Sascha mentioned a plan in the git list of using git as a
 backend. I pointed out a few (serious IMHO) limitations in git.

Even if git is not appropriate, I have found the following doc about
git's design very useful in clarifying some aspects of versioned data
repositories:

http://www.newartisans.com/2008/04/git-from-the-bottom-up.html

Regards,

Tomeu

 My general comment is:

  - apps will want to work on files larger than memory
  - apps will want to mmap files
  - apps will want to create/edit multi-file projects (ie: creating websites)

 those are complex constraints, but should be considered.

 /ot

 cheers,


 martin
 --
  martin.langh...@gmail.com
  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

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

[Sugar-devel] [RELEASE] Get Internet Archive Books-2

2009-07-03 Thread Sugar Labs Activities

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

Release notes:
This version fixes several bugs that were in version 1, allows downloading 
three different ebook formats (Color PDF, B/W PDF, and Deja Vu) instead of just 
Deja Vu, adds a progress bar to show how the downloading of books is 
progressing, and allows entries in the search results table to wrap to more 
than one line if they have long titles or lists of authors or both.  This 
Activity has a new icon, and works better on the XO screen than version 1 did.

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

Re: [Sugar-devel] Journal feature request--more data in main display

On Fri, Jul 03, 2009 at 11:01:25AM +0200, Martin Langhoff wrote:
 On Fri, Jul 3, 2009 at 5:29 AM, Gary C Marting...@garycmartin.com wrote:
  Aleksey was keen to see any Journal mock-up work in progress I had,
  early as possible, so here's where I'm at :-) There's plenty to do
  still, images are intended to help bounce ideas about, poke at the
  grey matter between our ears, and get a feel for how things could (or
  not) be done:
 
         
  http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes
 
 Very cool. I do agree the filter is very culture-dependent.
 
 On a similar vein, the 'tag' icon has no visual association with the
 many tags on screen. If they had a similar shape, then it'd be easy to
 connect, for users who don't recognise a tag and the (somewhat odd)
 use of tag to mean a bit of metadata on a digital resource.
 
 Wishlist: show files by size filter or option? If the Uruguay
 experience is any indicator, a fact of life is that users after all
 *will* hit:
 
  - problems with fitting files (large and small) in USB disks
 
  - problems with their Journal taking too much space
 
  - problems with installed Activities taking too much disk space

It could be utilized in different list view layout
some of[1] these layout could have column for size and users can sort by
this column.

[1] http://wiki.sugarlabs.org/go/File:-3.png

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

Re: [Sugar-devel] On datastore object IDs

On Thu, Jul 2, 2009 at 20:44, Eben Eliasone...@laptop.org wrote:
 On Thu, Jul 2, 2009 at 2:21 PM, Benjamin M.
 Schwartzbmsch...@fas.harvard.edu wrote:
 Eben Eliason wrote:
 On Thu, Jul 2, 2009 at 1:40 PM, Benjamin M.
 Schwartzbmsch...@fas.harvard.edu wrote:
 Eben Eliason wrote:

 If editing a Document's metadata produces a new Document, as befitting our
 Copy-on-Write model of versioning, then the process of editing the
 associated_actions field produces a new version.  Therefore, every time
 an Action adds a Document to itself, the process of adding the
 back-reference would produce a new version of the Document, so only one
 Action would ever end up referring to one version of the a Document.

 Metadata is attached to the version, I believe. I don't think we
 should be versioning metadata, so I don't think that it makes sense to
 create a new version when changing the metadata.

 I don't see such a big distinction between the data and metadata.  In
 fact, Activities whose state is easily represented as key:value pairs can
 put their entire state into the metadata, instead of storing it in a blob.

 Hmm, I do see a distinction, actually. Though Perhaps it depends on
 the the type. As an example:

 1. I make an image.
 2. I make several changes to this image over time, resulting in new versions.
 3. I decide that one of these intermediate images was meaningful in
 some way, and desire to tag it accordingly.

 I definitely don't want changing the description, or the tags, on some
 previous version to inadvertently a) make a new version and b) make
 that new version the most recent (and therefore most exposed) version.

 Perhaps we need to bite the bullet and consider having both versioned
 and unversioned metadata...

I think so. I definitely see part of the state of an activity stored
in the metadata (current page, current paint tool, etc). But we have
also some metadata properties that are bits of info about that
particular entry: author, title, tags, 'keep', etc. I think that we
should be able to modify those ones without creating a new version.

In fact, Ben's versioned prototype had all the blob and metadata
versioned and we needed to make some properties non-versioned because
of the intended user experience.

Regards,

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

Re: [Sugar-devel] Journal feature request--more data in main display

On Fri, Jul 3, 2009 at 11:01, Martin Langhoffmartin.langh...@gmail.com wrote:
 On Fri, Jul 3, 2009 at 5:29 AM, Gary C Marting...@garycmartin.com wrote:
 Aleksey was keen to see any Journal mock-up work in progress I had,
 early as possible, so here's where I'm at :-) There's plenty to do
 still, images are intended to help bounce ideas about, poke at the
 grey matter between our ears, and get a feel for how things could (or
 not) be done:

        
 http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes

 Very cool. I do agree the filter is very culture-dependent.

 On a similar vein, the 'tag' icon has no visual association with the
 many tags on screen. If they had a similar shape, then it'd be easy to
 connect, for users who don't recognise a tag and the (somewhat odd)
 use of tag to mean a bit of metadata on a digital resource.

 Wishlist: show files by size filter or option?

I think that's a good idea. Could we have a ticket for it? And maybe
also a shorter term one to display the file size somewhere?

Thanks,

Tomeu

 If the Uruguay
 experience is any indicator, a fact of life is that users after all
 *will* hit:

  - problems with fitting files (large and small) in USB disks

  - problems with their Journal taking too much space

  - problems with installed Activities taking too much disk space

 cheers,



 m
 --
  martin.langh...@gmail.com
  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

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

Re: [Sugar-devel] How to create a project on SugarLabs gitorious?

2009-07-03 Thread Bastien

Luke Faraone l...@faraone.cc writes:

 On Thu, Jul 2, 2009 at 06:13, Bastien bastiengue...@googlemail.com wrote:

 Bastien b...@laptop.org writes:

  See this wiki page: http://wiki.sugarlabs.org/go/Activity_Team/Git_FAQ
 
  That's it, thanks.

 I have uploaded my id_dsa.pub key on my account.

 Please try again with RSA, use of DSA is discouraged.

Thanks.

I had both DSA and RSA keys on gitorious.  I deleted the DSA key.
I still get this annoying error:

,
| Access denied or bad repository path
| fatal: The remote end hung up unexpectedly
`

My email on .gitconfig and gitorious are the same.  I have this error
from several IP addresses, so I guess I'm not blacklisted.

Here is my ~/Activities/Helpfr.activity/.git/config file:

,
| [core]
|   repositoryformatversion = 0
|   filemode = true
|   bare = false
|   logallrefupdates = true
| [remote origin]
|   url = gitori...@git.sugarlabs.org:helpfr/mainline.git
|   fetch = +refs/heads/*:refs/remotes/origin/*
| [push]
|   default = matching
`

Any other idea?

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

Re: [Sugar-devel] [Marketing] netbook as terminology

2009-07-03 Thread Frederick Grose

On Fri, Jul 3, 2009 at 10:36 AM, Walter Bender walter.ben...@gmail.comwrote:

 ...

 I don't know that we should decide to push a name change on the market.



...



Even in the developed world, the Internet is not everywhere, e.g., most
 classrooms, and as much as it has been good for the service providers to
 pitch it as true, the cloud is not right solution to every problem.


When we speak of netbooks, we can highlight Sugar's intrinsic ability to
network and collaborate without the Internet; so, not Internet-book, but
network-book!

XO-1s do this by default, we should push this capability into any Wi-Fi
enabled device running Sugar.

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

Re: [Sugar-devel] On datastore object IDs

2009-07-03 Thread Michael Stone

On Thu, Jul 2, 2009 at 20:44, Eben Eliasone...@laptop.org wrote:
 Hmm, I do see a distinction, actually. Though Perhaps it depends on
 the the type. As an example:

 1. I make an image.
 2. I make several changes to this image over time, resulting in new versions.
 3. I decide that one of these intermediate images was meaningful in
 some way, and desire to tag it accordingly.

 I definitely don't want changing the description, or the tags, on some
 previous version to inadvertently a) make a new version and b) make
 that new version the most recent (and therefore most exposed) version.

 Perhaps we need to bite the bullet and consider having both versioned
 and unversioned metadata...

I find that Section 5.4 of the XAM Architecture:

   http://www.snia.org/forums/xam/technology/specs/XAM_Arch_v1.0-approved.pdf

which was an inspiration for olpcfs, provides superior terminology for this
issue:

   whenever binding fields of content (an XSet) are changed, the name (XUID)
   by which that content is known changes.

   nonbinding fields may be changed without altering the name (the XUID) by
   which content is known

Regards,

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

[Sugar-devel] poor man's mmap sliding window on Python 2.5.x

2009-07-03 Thread Martin Langhoff

Still working on reading and validating Canonical JSON files that are
larger than available memory.

Along the way, found that Python 2.5.x doesn't support an offset to
mmap(), which at first blush makes re-mapping with a sliding window
problematic. Well, almost. If you mmap.close(), re-create the mmap and
start reading at an offset (m[myoffset]), python knows how to DTRT.

So every N number of reads (random or linear), close and re-mmap the
fh. If the reads are short, the memory used by N reads will be roughly

   N * mmap.PAGESIZE

Where pagesize is usually, 4KB. So re-mapping every 4MB for example
keeps the whole process under 6MB while working through a file that is
183MB.

On the XO-1, it's the difference of churning through it and slowing
the whole OS to a crawl, and then inching towards a big OOM zap.

cheers,



martin
-- 
 martin.langh...@gmail.com
 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] [IAEP] [Marketing] netbook as terminology

2009-07-03 Thread Bastien

Frederick Grose fgr...@gmail.com writes:

 When we speak of netbooks, we can highlight Sugar's intrinsic ability to
 network and collaborate without the Internet; so, not Internet-book, but
 network-book!

 XO-1s do this by default, we should push this capability into any Wi-Fi 
 enabled
 device running Sugar.

Yes.  In the meantime, I would *love* to see the XS server running, and
a tutorial on how to use Sugar with non-XO computers connected thru a XS
server...  IMHO it's a promise that OLPC/Sugar cannot afford to bypass.

For example, there are many schools in France where they use an
Ubuntu-based distribution (AbulEdu) as a server and let the children
computers interact through this server.  When I talk to them about
Sugar, they immediately ask about the server.

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

Re: [Sugar-devel] [IAEP] [Marketing] netbook as terminology

On Fri, Jul 3, 2009 at 18:03, Frederick Grosefgr...@gmail.com wrote:
 On Fri, Jul 3, 2009 at 10:36 AM, Walter Bender walter.ben...@gmail.com
 wrote:

 ...

 I don't know that we should decide to push a name change on the market.



 ...



 Even in the developed world, the Internet is not everywhere, e.g., most
 classrooms, and as much as it has been good for the service providers to
 pitch it as true, the cloud is not right solution to every problem.

 When we speak of netbooks, we can highlight Sugar's intrinsic ability to
 network and collaborate without the Internet; so, not Internet-book, but
 network-book!

 XO-1s do this by default, we should push this capability into any Wi-Fi
 enabled device running Sugar.

Getting there!

http://blog.tomeuvizoso.net/2009/05/ad-hoc-wireless-networks-in-sugar.html

Regards,

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

Re: [Sugar-devel] [IAEP] Communicating project goals and Roadmap

2009-07-03 Thread Frederick Grose

On Fri, Jul 3, 2009 at 9:27 AM, Tomeu Vizoso to...@sugarlabs.org wrote:

 2009/7/2 Sean DALY sdaly...@gmail.com:
  I don't know Tomeu, what do you think?

 I sincerely don't know but I hope that someone will explain what they
 need from the development team to succeed.


The idea is that *all* of Sugar Labs needs to think deeply about how we
develop the next stage of Sugar and Sugar Labs.  What is most important to
refine and advance, and what important pieces need to be added.

This seems to be a followup to the call for *Champions* to advocate for the
features needed to better serve our communities.  Champions that can
integrate with the Design, Development, Activity, Education, Deployment,
Marketing, and other Teams.

For example, see this discussion thread on the 'netbook' as terminology,
http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg05906.html,
and the suggestion to push ad-hoc wireless networking into a native feature
of Sugar.  This would give Sugar a large, advantageous multiplier effect for
creating more pervasive networking to take advantage of our core feature,
collaboration.

Powerful ideas please step forward...

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

Re: [Sugar-devel] [IAEP] Communicating project goals and Roadmap

On Fri, Jul 3, 2009 at 19:00, Frederick Grosefgr...@gmail.com wrote:

 On Fri, Jul 3, 2009 at 9:27 AM, Tomeu Vizoso to...@sugarlabs.org wrote:

 2009/7/2 Sean DALY sdaly...@gmail.com:
  I don't know Tomeu, what do you think?

 I sincerely don't know but I hope that someone will explain what they
 need from the development team to succeed.

 The idea is that *all* of Sugar Labs needs to think deeply about how we
 develop the next stage of Sugar and Sugar Labs.  What is most important to
 refine and advance, and what important pieces need to be added.

 This seems to be a followup to the call for *Champions* to advocate for the
 features needed to better serve our communities.  Champions that can
 integrate with the Design, Development, Activity, Education, Deployment,
 Marketing, and other Teams.

 For example, see this discussion thread on the 'netbook' as terminology,
 http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg05906.html,
 and the suggestion to push ad-hoc wireless networking into a native feature
 of Sugar.  This would give Sugar a large, advantageous multiplier effect for
 creating more pervasive networking to take advantage of our core feature,
 collaboration.

 Powerful ideas please step forward...

That's a good example, someone (several people?) have expressed in the
past that creating ad-hoc networks would be of great value, and at
some point I found some time and implemented it.

Development being driven by the development team doesn't mean that
only gets done what fancies us, we are always asking for feedback and
can be convinced to spend our time on other people's ideas.

Regards,

Tomeu

    --Fred



 ___
 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] Journal feature request--more data in main display

Hi Aleksey,

On 3 Jul 2009, at 05:25, Aleksey Lim wrote:
 On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote:
 Aleksey was keen to see any Journal mock-up work in progress I had,
 early as possible, so here's where I'm at :-) There's plenty to do
 still, images are intended to help bounce ideas about, poke at the  
 grey
 matter between our ears, and get a feel for how things could (or  
 not) be
 done:

  
 http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes

 Some thoughts:

 * what about adding ultra compact list view for objects(not actions)
  like list view in Library[1]
  the purpose is, if user has lots of objects it could be useful idea  
 to
  show as much as possible objects on one screen

We do want to show plenty of entries, but need to keep in mind visible  
size of each text/icon row entry. My current call is to make each  
Journal entry row 'richer' rather than trying to cram on more rows  
(encourage folks to search/filter down to a small number of results).  
The grid view is better for looking and scrubbing through many  
entries. In Library you've made your rows richer by adding many more  
options for showing extra columns of information (author, artist,  
date, album, disk, track, genre, copyright, ...) at the cost of lots  
of horizontal scrolling, and option complexity.

  * having several column/grid layouts
for example its very useful for books to have columns for author,
genre, date; so, user can see the whole valuable info at once and  
 sort
objects by these columns; and so separate layouts for video audio
etc. files

The option complexity is too high for me, and causes horizontal  
scrolling (mentioned above), though the ability to sort on any  
arbitrary column is a bonus. Personally I think all the extra column  
information would be much better treated as tags, that way you can use  
the existing Journal tagging mechinisum, search and drill down to the  
entries you are after, and with the title + tag row entry still get to  
directly browse that information if needed.

 * additional types of filters
  for example Library has[2] several types to filter objects

As a user, I don't like to see dot notation bundle id's displayed in  
the UI (i.e org.laptop.sugar.ReadEtextsActivity), it's way too  
scary :-) I think the anything/what activity/mime filter is more user  
friendly.

  * user tags

Library does confuse me here in that it seems to have it's on separate  
tagging data and process while ignoring actual Journal tag metadata.

  * object traits(additional columns from previous section) like  
 author,
genre, date for books

Found this separation confusing, if really necessary, are 'traits' not  
just tags?

  * activity creators(grouping by activity_id field)

Yes, I have a TODO to add a button and palette for anyone/who.

  * types of objects(like top section in filter palette)[3]

Yep, that's my anything/what funnel filter icon (looking for better  
icon) :-)

  * filter by participants

I see that as part of above anyone/who. The most common filter would  
be to be able to search for Journal entries from Walter.

  * filter by sources(if we are in shared mode)

For your Library Activity, but not sure this is relevant (in short to  
mid term) for Journal. And, perhaps covered by above anyone/who  
filter. Once you 'borrow' an entry you now have a local copy in the  
user colours of the person you borrowed from.

  I'm not sure that all of these modes are useful, but something could
  be(or another types)

 * several levels of chosen filters
  dunno about others but for me its very useful
  (see bottom panel on [4])
  for example I can filter all text/plane files and separate from them
  only objects that were made by Terminal activity

I found this complicated in Library, actually I'm not sure I have is  
solved yet :-) I think tagging is a simple wide ranging panacea for  
many of these types of search.

 [1] http://wiki.sugarlabs.org/go/File:-3.png
 [2] http://wiki.sugarlabs.org/go/File:-1.png
 [3] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#.232
 [4] http://wiki.sugarlabs.org/go/File:-4.png

I have Library-1 as per activities.sugarlabs.org but my screens look  
slightly different to your screenshots (you have more side bar icons  
than I see). Is there another version I should be looking at?

Thanks for all the feedback!
--Gary

P.S. I'm still hacking on the 
http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes 
   mock-ups, so this is all great stuff to keep in mind while I tweak.

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

[Sugar-devel] soas strawberry sha1sum?

2009-07-03 Thread Sameer Verma

I'm getting 41b08c93a65cc1e38286b9f8980f51528a36761d is this correct?
I tried a usb stick, but keep getting bad or damaged partition at boot
time.

sameer
-- 
Dr. Sameer Verma, Ph.D.
Associate Professor of Information Systems
San Francisco State University
San Francisco CA 94132 USA
http://verma.sfsu.edu/
http://opensource.sfsu.edu/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Journal feature request--more data in main display

On 3 Jul 2009, at 05:53, Aleksey Lim wrote:

 On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote:
 * additional types of filters
  for example Library has[2] several types to filter objects

  * user tags
  * object traits(additional columns from previous section) like  
 author,
genre, date for books
  * activity creators(grouping by activity_id field)
  * types of objects(like top section in filter palette)[3]
  * filter by participants
  * filter by sources(if we are in shared mode)

  I'm not sure that all of these modes are useful, but something could
  be(or another types)

 like http://wiki.sugarlabs.org/go/File:-5.png

The filters (currently in Journal, and in my mock-ups) are in separate  
top level toolbar controls. I'm basically just switching them to icons  
instead of text menus. From your mock-up, User tags would be  
controlled via a palette (not yet finished the mock-up) from that tag/ 
label icon shown in the toolbar. Next to it will also be added a buddy  
icon (white outline) for a filter palette (not yet finished the mock- 
up) that looks like it would cover Participants.

Where you have Object types I understand that as file mime types,  
which was what I placed at the top of that palette before your mock-up  
modification :-)

Your Object traits I thing a best just dealt with in a universal way  
as tags, no new ontology needed and gets to benefit from any general  
tag improvements we make to Sugar (details entry, activity naming  
dialogue improvements, auto completion, 'tags under title' Journal  
entry display, the Object Chooser).

I'm not convinced I understand your Creators category. Is this  
original author, the Activity used to build the entry, or something  
else?

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

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote:
 On 2 Jul 2009, at 14:47, Eben Eliason wrote:

 On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote:

 But in that case we should provide possibility to mark objects that can
 be shared(I guess sharing all local objects by default is not a nice
 idea).

 Right. This would be essential. There's definitely some thought that
 needs to be done here.

 Scott had an interesting proposal which basically exposed the Journal
 (or some subset of it) as an RSS feed. This was really neat, because
 it meant we could build a UI for someone else's Journal in Sugar,
 populating it with that data, but also that these feeds could be
 shared globally, for anyone with an RSS reader to benefit from. That's
 a really powerful approach in my mind, and there is some starter code
 lying around as a proof of concept already!


 +1 to rss feed concept, makes life a lot easier in a heterogeneous
 environment.

 I'm still catching up on email so apologies if this has been mentioned
 already. But the UI for marking of entries as sharable does not necessarily
 need to be another Journal user-interface addition** In the simplest
 approach you could just extend the Activity Share with: my Neighbourhood
 control to mark a Journal entry as part of the RRS feed. Would need some

The problem I see with this is that we're talking about two different
kinds of sharing. Just because I want to make a picture I drew
available for anyone to look at, or even make a photocopy of to
scribble on, doesn't mean that I want to let them into a shared
painting session so they can scribble on the original with me.

This is the difference between sharing an activity with someone
collaboratively, and sending them (a copy of) the resulting object.

 thought on wording, do you add more levels of sharing? Or do you just
 simplify the Share with: language language to Private, Share with:
 Anyone.

 **though I would like entries to visually show their sharing state, the
 buddy column hints at this but should be made explicit

I do actually think that the Journal is the best place to expose this,
especially since the way we plan to expose the feature in the UI is
something like view my friend's Journal. I'm not sure exactly how
or where that happens. Perhaps if we can abandon the checkbox for the
multi-selection we can use that space for a public/private toggle of
some kind.

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

Re: [Sugar-devel] Journal feature request--more data in main display

On 3 Jul 2009, at 06:13, Aleksey Lim wrote:

 On Fri, Jul 03, 2009 at 05:06:30AM +, Aleksey Lim wrote:
 On Fri, Jul 03, 2009 at 04:53:42AM +, Aleksey Lim wrote:
 On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote:
 * additional types of filters
  for example Library has[2] several types to filter objects

  * user tags
  * object traits(additional columns from previous section) like  
 author,
genre, date for books
  * activity creators(grouping by activity_id field)
  * types of objects(like top section in filter palette)[3]
  * filter by participants
  * filter by sources(if we are in shared mode)

  I'm not sure that all of these modes are useful, but something  
 could
  be(or another types)

 like http://wiki.sugarlabs.org/go/File:-5.png

 use several types of view, list and cloud
 http://wiki.sugarlabs.org/go/File:-6.png

 I guess, having numbers of objects makes sense as well
 http://wiki.sugarlabs.org/go/File:-7.png

Yes if that information is easily/quickly available some may find that  
use full, it might be too much information clutter though. Likely more  
useful for the tag cloud, though I'd rather tag font size be used for  
immediate visual comparison. Tag cloud mock-up is still in progress,  
it'll go up on the wiki page as soon as it's done.

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

Re: [Sugar-devel] Journal feature request--more data in main display

On Fri, Jul 03, 2009 at 06:13:24PM +0100, Gary C Martin wrote:
 Hi Aleksey,

 On 3 Jul 2009, at 05:25, Aleksey Lim wrote:
 On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote:
 Aleksey was keen to see any Journal mock-up work in progress I had,
 early as possible, so here's where I'm at :-) There's plenty to do
 still, images are intended to help bounce ideas about, poke at the  
 grey
 matter between our ears, and get a feel for how things could (or  
 not) be
 done:

 
 http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes

 Some thoughts:

 * what about adding ultra compact list view for objects(not actions)
  like list view in Library[1]
  the purpose is, if user has lots of objects it could be useful idea  
 to
  show as much as possible objects on one screen

 We do want to show plenty of entries, but need to keep in mind visible  
 size of each text/icon row entry. My current call is to make each  
 Journal entry row 'richer' rather than trying to cram on more rows  
 (encourage folks to search/filter down to a small number of results).  

Maybe having several views/layouts(for several purposes) is more useful 
idea then only one common view for all purposes?  I mean:

* compact view
  could be not trivial(horizontal scrolls) but highly
  configured(show/hide columns)
  for people who want narrow lines with additional columns
  (to sort them for example)
* grid view
  and use filters to show what user needs(because there could a lack
  of useful info in this view)

 The grid view is better for looking and scrubbing through many entries. 
 In Library you've made your rows richer by adding many more options for 
 showing extra columns of information (author, artist, date, album, disk, 
 track, genre, copyright, ...) at the cost of lots of horizontal 
 scrolling, and option complexity.

  * having several column/grid layouts
for example its very useful for books to have columns for author,
genre, date; so, user can see the whole valuable info at once and  
 sort
objects by these columns; and so separate layouts for video audio
etc. files

 The option complexity is too high for me, and causes horizontal  
 scrolling (mentioned above), though the ability to sort on any arbitrary 
 column is a bonus. Personally I think all the extra column information 
 would be much better treated as tags, that way you can use the existing 
 Journal tagging mechinisum, search and drill down to the entries you are 
 after, and with the title + tag row entry still get to directly browse 
 that information if needed.

 * additional types of filters
  for example Library has[2] several types to filter objects

 As a user, I don't like to see dot notation bundle id's displayed in the 
 UI (i.e org.laptop.sugar.ReadEtextsActivity), it's way too scary :-) I 
 think the anything/what activity/mime filter is more user friendly.

thats was just first implementation(further it will be activity names)

  * user tags

 Library does confuse me here in that it seems to have it's on separate  
 tagging data and process while ignoring actual Journal tag metadata.

The problem is - user can use any symbols in tag name(including spaces)
at the same time Library needs datastore to make exact query by this
tag and do not mess tag name with words in description field for
example.

So Library stores tags in json string with structure:
[(pretty-tag-name, __tag_name_especially_to_make_exact_query__),..]
thats why this string goes to _tags_ field and not to tags.

  * object traits(additional columns from previous section) like  
 author,
genre, date for books

 Found this separation confusing, if really necessary, are 'traits' not  
 just tags?

thats because they live in separate DS fields to let users sort objects
by them

  * activity creators(grouping by activity_id field)

 Yes, I have a TODO to add a button and palette for anyone/who.

  * types of objects(like top section in filter palette)[3]

 Yep, that's my anything/what funnel filter icon (looking for better  
 icon) :-)

  * filter by participants

 I see that as part of above anyone/who.

The most common filter would be 
 to be able to search for Journal entries from Walter.

but in that case user would get all objects with substring Walter
not only objects with participant Walter

  * filter by sources(if we are in shared mode)

 For your Library Activity, but not sure this is relevant (in short to  
 mid term) for Journal. And, perhaps covered by above anyone/who filter. 
 Once you 'borrow' an entry you now have a local copy in the user colours 
 of the person you borrowed from.

yeah, thats should rethinking during implementation of sharing objects

  I'm not sure that all of these modes are useful, but something could
  be(or another types)

 * several levels of chosen filters
  dunno about others but for me its very useful
  (see bottom panel on [4])
  for example I can filter all text/plane files and separate from

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

On Fri, Jul 03, 2009 at 01:29:56PM -0400, Eben Eliason wrote:
 On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote:
  On 2 Jul 2009, at 14:47, Eben Eliason wrote:
 
  On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote:
 
  But in that case we should provide possibility to mark objects that can
  be shared(I guess sharing all local objects by default is not a nice
  idea).
 
  Right. This would be essential. There's definitely some thought that
  needs to be done here.
 
  Scott had an interesting proposal which basically exposed the Journal
  (or some subset of it) as an RSS feed. This was really neat, because
  it meant we could build a UI for someone else's Journal in Sugar,
  populating it with that data, but also that these feeds could be
  shared globally, for anyone with an RSS reader to benefit from. That's
  a really powerful approach in my mind, and there is some starter code
  lying around as a proof of concept already!
 
 
  +1 to rss feed concept, makes life a lot easier in a heterogeneous
  environment.
 
  I'm still catching up on email so apologies if this has been mentioned
  already. But the UI for marking of entries as sharable does not necessarily
  need to be another Journal user-interface addition** In the simplest
  approach you could just extend the Activity Share with: my Neighbourhood
  control to mark a Journal entry as part of the RRS feed. Would need some
 
 The problem I see with this is that we're talking about two different
 kinds of sharing. Just because I want to make a picture I drew
 available for anyone to look at, or even make a photocopy of to
 scribble on, doesn't mean that I want to let them into a shared
 painting session so they can scribble on the original with me.
 
 This is the difference between sharing an activity with someone
 collaboratively, and sending them (a copy of) the resulting object.
 
  thought on wording, do you add more levels of sharing? Or do you just
  simplify the Share with: language language to Private, Share with:
  Anyone.
 
  **though I would like entries to visually show their sharing state, the
  buddy column hints at this but should be made explicit
 
 I do actually think that the Journal is the best place to expose this,
 especially since the way we plan to expose the feature in the UI is
 something like view my friend's Journal. I'm not sure exactly how
 or where that happens. Perhaps if we can abandon the checkbox for the
 multi-selection we can use that space for a public/private toggle of
 some kind.

so, you think that my idea of Pins looks ugly :)
http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016025.html

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

Re: [Sugar-devel] soas strawberry sha1sum?

2009-07-03 Thread Sebastian Dziallas

Sameer Verma wrote:
 I'm getting 41b08c93a65cc1e38286b9f8980f51528a36761d is this correct?
 I tried a usb stick, but keep getting bad or damaged partition at boot
 time.

 sameer

Yup, it is: http://download.sugarlabs.org/soas/releases/SHA1SUM

Bad or damaged partition errors? Maybe your USB key is broken?

You could try burning the .iso image to a CD to see if it works there...

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

Re: [Sugar-devel] Journal feature request--more data in main display

On Fri, Jul 03, 2009 at 06:36:07PM +0100, Gary C Martin wrote:

 On 3 Jul 2009, at 06:06, Aleksey Lim wrote:

 On Fri, Jul 03, 2009 at 04:53:42AM +, Aleksey Lim wrote:
 On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote:
 * additional types of filters
  for example Library has[2] several types to filter objects

  * user tags
  * object traits(additional columns from previous section) like  
 author,
genre, date for books
  * activity creators(grouping by activity_id field)
  * types of objects(like top section in filter palette)[3]
  * filter by participants
  * filter by sources(if we are in shared mode)

  I'm not sure that all of these modes are useful, but something  
 could
  be(or another types)

 like http://wiki.sugarlabs.org/go/File:-5.png

 use several types of view, list and cloud
 http://wiki.sugarlabs.org/go/File:-6.png

 I think we may now be talking about different features/options :-)  
 Apologies if so, but...

 List view (for me) is the top right toolbar icon already shown, it  
 shows all entries as a row list, as shown, and just like the current  
 Journal.

We really think talking about different features/options :)

I meant grouped list, for example if we chose users tags type of filter
(ok, thats discussable:) this list will be a list of tags; if we chose
object types type it will be a list of object types

 Cloud view (for me) will be what you see (or something close) when you 
 click on that tag/label icon showing the main toolbar. It will show a 
 palette that display current Journal tags in an efficient space manor.

yup, exactly what I mean here(and so for list view from prev. paragraph)

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

Re: [Sugar-devel] Journal feature request--more data in main display

On Fri, Jul 03, 2009 at 06:40:37PM +0100, Gary C Martin wrote:
 On 3 Jul 2009, at 06:13, Aleksey Lim wrote:

 On Fri, Jul 03, 2009 at 05:06:30AM +, Aleksey Lim wrote:
 On Fri, Jul 03, 2009 at 04:53:42AM +, Aleksey Lim wrote:
 On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote:
 * additional types of filters
  for example Library has[2] several types to filter objects

  * user tags
  * object traits(additional columns from previous section) like  
 author,
genre, date for books
  * activity creators(grouping by activity_id field)
  * types of objects(like top section in filter palette)[3]
  * filter by participants
  * filter by sources(if we are in shared mode)

  I'm not sure that all of these modes are useful, but something  
 could
  be(or another types)

 like http://wiki.sugarlabs.org/go/File:-5.png

 use several types of view, list and cloud
 http://wiki.sugarlabs.org/go/File:-6.png

 I guess, having numbers of objects makes sense as well
 http://wiki.sugarlabs.org/go/File:-7.png

 Yes if that information is easily/quickly available some may find that  
 use full, it might be too much information clutter though. Likely more  
 useful for the tag cloud, though I'd rather tag font size be used for  
 immediate visual comparison. Tag cloud mock-up is still in progress,  
 it'll go up on the wiki page as soon as it's done.

yeah it was only for list view(of tags)
cloud is all about font sizes instead of explicitly mentioned counts

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

Re: [Sugar-devel] Journal feature request--more data in main display

On 3 Jul 2009, at 10:01, Martin Langhoff wrote:

 On Fri, Jul 3, 2009 at 5:29 AM, Gary C Marting...@garycmartin.com  
 wrote:
 Aleksey was keen to see any Journal mock-up work in progress I had,
 early as possible, so here's where I'm at :-) There's plenty to do
 still, images are intended to help bounce ideas about, poke at the
 grey matter between our ears, and get a feel for how things could (or
 not) be done:


 http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes

 Very cool. I do agree the filter is very culture-dependent.

 On a similar vein, the 'tag' icon has no visual association with the
 many tags on screen. If they had a similar shape, then it'd be easy to
 connect, for users who don't recognise a tag and the (somewhat odd)
 use of tag to mean a bit of metadata on a digital resource.

I just 'acquired' the tag/label icon from Eben's mock-ups. Assume he  
had though about this way more than me :-) Sure there are plenty of  
revisions, reworks, and cherry picking.

 Wishlist: show files by size filter or option? If the Uruguay
 experience is any indicator, a fact of life is that users after all
 *will* hit:

 - problems with fitting files (large and small) in USB disks

 - problems with their Journal taking too much space

 - problems with installed Activities taking too much disk space

Good point! Though arbitrary Journal sorting likely breaks many design  
goals***, otherwise you'd have thought we would have the most basic of  
features, sort by creation date, by now ;-) At the very least size  
taken by an entry should be visible on the details view. Right now  
there is zero indication other than just watching your total Journal  
grow in size via it's frame icon.

***Eben can you clarify this one? If locking folks into a 'view  
Journal only by modification date' was an intentional design choice?

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

Re: [Sugar-devel] [IAEP] [Marketing] netbook as terminology

2009-07-03 Thread Dave Bauer

On Fri, Jul 3, 2009 at 12:19 PM, Bastien bastiengue...@googlemail.comwrote:

 Frederick Grose fgr...@gmail.com writes:

  When we speak of netbooks, we can highlight Sugar's intrinsic ability to
  network and collaborate without the Internet; so, not Internet-book, but
  network-book!
 
  XO-1s do this by default, we should push this capability into any Wi-Fi
 enabled
  device running Sugar.

 Yes.  In the meantime, I would *love* to see the XS server running, and
 a tutorial on how to use Sugar with non-XO computers connected thru a XS
 server...  IMHO it's a promise that OLPC/Sugar cannot afford to bypass.


This is already working. For example, if you use Sugar on a Stick you are
using an XS that can work with XO and non-XO computers today. This is 0.5.2
XS installed from the ISO and regularly updated via yum. If you take any
installation of Sugar and set the collaboration server to
jabber.sugarlabs.org it should work. No special configuration is needed to
support Sugar on non-XO computers that I am aware of.

Dave


 For example, there are many schools in France where they use an
 Ubuntu-based distribution (AbulEdu) as a server and let the children
 computers interact through this server.  When I talk to them about
 Sugar, they immediately ask about the server.

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




-- 
Dave Bauer
d...@solutiongrove.com
http://www.solutiongrove.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Journal feature request--more data in main display

2009-07-03 Thread James Zaki

Perhaps this is a late reply, (I am yet to read the last 6 or so digests of
to 20+ that were in my inbox)
But I am always sensitive of little incremental additions that seem like it
would be useful.

I always try to think about the first time I used sugar. In particular, what
helped by being very simple. We see sugar evolving, and perhaps forget what
it was like that first time. Perhaps we should harass some friends and
families' kids who've not seen it, and get their feedback.

If a child new to the sugar interface (XO or otherwise) feels bombarded with
options, it could make things harder.
Just my two cents I always voice on this.

In particular to the pictures, apart from the two identical cloud icons,
there are lots of activities in that dropdown. Has that always been so big?
To me that would be intimidating for the first user experience.

James.



 Date: Fri, 3 Jul 2009 04:25:54 +
 From: Aleksey Lim alsr...@member.fsf.org
 Subject: Re: [Sugar-devel] Journal feature request--more data in main
display
 To: Gary C Martin g...@garycmartin.com
 Cc: Sugar Devel sugar-devel@lists.sugarlabs.org
 Message-ID: 20090703042553.ga15...@antilopa-gnu
 Content-Type: text/plain; charset=us-ascii

 On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote:
  On 2 Jul 2009, at 02:40, Gary C Martin wrote:
 
  On 1 Jul 2009, at 10:54, Tomeu Vizoso wrote:
  On Mon, Jun 29, 2009 at 18:14, Gary C Marting...@garycmartin.com
  wrote:
  - Better Anything toolbar filter palette (use a grid layout to
  minimise
  scrolling)
 
  Yeah, that will be great. I think Walter already submitted a patch to
  move the file types up.
 
  Yea, saw the patch from Walter, that alone should help even if we
  stall on doing more.
 
  I have a mock-up I was experimenting with grid layouts, still
  tinkering, and I can't think of a good 'filter' icon for the
  replacement button (a common one seems to be a funnel shape) :-)
 
  The Journal filters for 'Anything', 'Anytime', the proposed 'Anyone',
  and my below 'Tag' filters can all become toolbar icons (not text).
  This saves a heap of toolbar space, and allows room for a couple more
  buttons on the far right for 'Grid' and current 'List' view.
 
  Aleksey was keen to see any Journal mock-up work in progress I had,
  early as possible, so here's where I'm at :-) There's plenty to do
  still, images are intended to help bounce ideas about, poke at the grey
  matter between our ears, and get a feel for how things could (or not) be
  done:
 
 
 http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes

 Some thoughts:

 * what about adding ultra compact list view for objects(not actions)
  like list view in Library[1]
  the purpose is, if user has lots of objects it could be useful idea to
  show as much as possible objects on one screen

  * having several column/grid layouts
for example its very useful for books to have columns for author,
genre, date; so, user can see the whole valuable info at once and sort
objects by these columns; and so separate layouts for video audio
etc. files

 * additional types of filters
  for example Library has[2] several types to filter objects

  * user tags
  * object traits(additional columns from previous section) like author,
genre, date for books
  * activity creators(grouping by activity_id field)
  * types of objects(like top section in filter palette)[3]
  * filter by participants
  * filter by sources(if we are in shared mode)

  I'm not sure that all of these modes are useful, but something could
  be(or another types)

 * several levels of chosen filters
  dunno about others but for me its very useful
  (see bottom panel on [4])
  for example I can filter all text/plane files and separate from them
  only objects that were made by Terminal activity


 [1] http://wiki.sugarlabs.org/go/File:-3.png
 [2] http://wiki.sugarlabs.org/go/File:-1.png
 [3] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#.232
 [4] http://wiki.sugarlabs.org/go/File:-4.png

 --
 Aleksey


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

Re: [Sugar-devel] soas strawberry sha1sum?

2009-07-03 Thread Sean DALY

Sameer, in my experience sticks are not nearly as reliable as CDs in
terms of loading a bootable image, apparently due to internal firmware
and chip differences

I believe Caroline was getting some failures even with identical make
 model sticks in the Nexcopy mass loader.

Sean


On Fri, Jul 3, 2009 at 8:09 PM, Sebastian Dziallassebast...@when.com wrote:
 Sameer Verma wrote:
 I'm getting 41b08c93a65cc1e38286b9f8980f51528a36761d is this correct?
 I tried a usb stick, but keep getting bad or damaged partition at boot
 time.

 sameer

 Yup, it is: http://download.sugarlabs.org/soas/releases/SHA1SUM

 Bad or damaged partition errors? Maybe your USB key is broken?

 You could try burning the .iso image to a CD to see if it works there...

 --Sebastian
 ___
 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] Journal feature request--more data in main display

On Fri, Jul 03, 2009 at 08:29:10PM +0200, James Zaki wrote:
 Perhaps this is a late reply, (I am yet to read the last 6 or so digests of
 to 20+ that were in my inbox)
 But I am always sensitive of little incremental additions that seem like it
 would be useful.
 
 I always try to think about the first time I used sugar. In particular, what
 helped by being very simple. We see sugar evolving, and perhaps forget what
 it was like that first time. Perhaps we should harass some friends and
 families' kids who've not seen it, and get their feedback.

Unfortunately we are limited in our resources, for example wadeb managed
to produce only ONE(thats a shame!) new sugar user for past year.

 If a child new to the sugar interface (XO or otherwise) feels bombarded with
 options, it could make things harder.
 Just my two cents I always voice on this.
 
 In particular to the pictures, apart from the two identical cloud icons,
 there are lots of activities in that dropdown. Has that always been so big?
 To me that would be intimidating for the first user experience.

Thats a good point, thanks for this

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

Re: [Sugar-devel] soas strawberry sha1sum?

2009-07-03 Thread Marten Vijn

On Fri, 2009-07-03 at 20:32 +0200, Sean DALY wrote:
 Sameer, in my experience sticks are not nearly as reliable as CDs in
 terms of loading a bootable image, apparently due to internal firmware
 and chip differences

sometimes zeroing the drive helps

dd if=/dev/zero of=/dev/drive bs=10M


kind regards,
Marten
 

 
 I believe Caroline was getting some failures even with identical make
  model sticks in the Nexcopy mass loader.
 
 Sean
 
 
 On Fri, Jul 3, 2009 at 8:09 PM, Sebastian Dziallassebast...@when.com wrote:
  Sameer Verma wrote:
  I'm getting 41b08c93a65cc1e38286b9f8980f51528a36761d is this correct?
  I tried a usb stick, but keep getting bad or damaged partition at boot
  time.
 
  sameer
 
  Yup, it is: http://download.sugarlabs.org/soas/releases/SHA1SUM
 
  Bad or damaged partition errors? Maybe your USB key is broken?
 
  You could try burning the .iso image to a CD to see if it works there...
 
  --Sebastian
  ___
  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
-- 
http://martenvijn.nl Marten Vijn 
http://martenvijn.nl/trac/wiki/soas  Sugar on a Stick
http://bsd.wifisoft.org/nek/ The Network Event Kit
http://har2009.org   13th-16th August 
http://opencommunitycamp.org 26th Jul - 2nd August

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

Re: [Sugar-devel] On datastore object IDs

2009-07-03 Thread Chris Marshall

Tomeu Vizoso wrote:
 On Thu, Jul 2, 2009 at 19:23, Benjamin M.
 Schwartzbmsch...@fas.harvard.edu wrote:
 Walter Bender wrote:
 Use case: I send you a presentation that refers to objects in the
 datastore. I need to send you those objects too, but I would not like
 to have to use some additional layer of reference.
 Heh.  We don't support inter-object dependencies.  It's amazing how we
 keep having the same discussion over and over, though:

 http://lists.laptop.org/pipermail/sugar/2007-April/002210.html

 Maybe this time we will come to the other conclusion?
 
 I'm still leaning in favour of self-contained bundles for both
 activities and journal entries. Both options have ups and downs but I
 think that the complexity of dealing with broken links/dependencies
 conflicts with our goal of simplicity.

One of the concepts from git that I really like is the
concept of the cryptographic data object IDs.  It allows
one to easily locate and compare objects and other git
constructs.

A similar type of globally, unique identifier could
allow migration, reference, and reconstitution of journal
objects or activities.  That might alleviate one problem
of broken links/dependencies in that you would definitely
know what should be there [at the other end of the link].

Maybe a type of Journal entry like Bobby's Photo with the
link and a Get the Photo action or starting/resuming an
Activity with it would get the needed object.

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

Re: [Sugar-devel] Trimming down ling wiki names

2009-07-03 Thread Frederick Grose

On Thu, Jul 2, 2009 at 9:06 AM, Frederick Grose fgr...@sugarlabs.orgwrote:

 On Thu, Jul 2, 2009 at 7:45 AM, Simon Schampijer si...@schampijer.dewrote:

 Hi Fred,

 it might makes sense to trim down our long wiki names. As we heavily use
 categories now - this might not be an issue. How about we do:

 http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.84 -
 http://wiki.sugarlabs.org/go/0.84/Roadmap

 and


 http://wiki.sugarlabs.org/go/Development_Team/Release/Releases/Sucrose/0.84-
 http://wiki.sugarlabs.org/go/0.84/Notes

 same for 0.82 and 0.86.

 What do you think? Can you do this without breaking current links?

 Regards,
   Simon


 That should be possible and fits with the idea that DFarning reported of
 broadening the involvement in the platform development.

 I'll start with 0.82, http://wiki.sugarlabs.org/go/0.82, and leave wiki
 redirects to catch those linking from off-site links in blogs and other
 references.

  --Fred


I've moved the Development Team/Releases branch to branches beginning with
0.82, 0.84, 0.86,  0.88 (the stable branches).   See now that
http://wiki.sugarlabs.org/go/Development_Team#Platform_Release_Cycles and
#/Subpages are a bit more readable.

I seem to have lost
http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.84 (notice
that it redirects to 0.86/Roadmap).  Perhaps it was never saved, but only
transformed into the 0.86 roadmap.

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

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

On 3 Jul 2009, at 18:29, Eben Eliason wrote:

 On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com  
 wrote:
 On 2 Jul 2009, at 14:47, Eben Eliason wrote:

 On Wed, Jul 1, 2009 at 1:42 PM, Aleksey  
 Limalsr...@member.fsf.org wrote:

 But in that case we should provide possibility to mark objects  
 that can
 be shared(I guess sharing all local objects by default is not a  
 nice
 idea).

 Right. This would be essential. There's definitely some thought that
 needs to be done here.

 Scott had an interesting proposal which basically exposed the  
 Journal
 (or some subset of it) as an RSS feed. This was really neat, because
 it meant we could build a UI for someone else's Journal in Sugar,
 populating it with that data, but also that these feeds could be
 shared globally, for anyone with an RSS reader to benefit from.  
 That's
 a really powerful approach in my mind, and there is some starter  
 code
 lying around as a proof of concept already!


 +1 to rss feed concept, makes life a lot easier in a heterogeneous
 environment.

 I'm still catching up on email so apologies if this has been  
 mentioned
 already. But the UI for marking of entries as sharable does not  
 necessarily
 need to be another Journal user-interface addition** In the simplest
 approach you could just extend the Activity Share with: my  
 Neighbourhood
 control to mark a Journal entry as part of the RRS feed. Would need  
 some

 The problem I see with this is that we're talking about two different
 kinds of sharing. Just because I want to make a picture I drew
 available for anyone to look at, or even make a photocopy of to
 scribble on, doesn't mean that I want to let them into a shared
 painting session so they can scribble on the original with me.

 This is the difference between sharing an activity with someone
 collaboratively, and sending them (a copy of) the resulting object.

Devils advocate here, so just because someone was late to the realtime  
party, they don't get to download an otherwise openly published piece  
of work that could be re-published at any time by any of the  
temporally lucky contributors? Downloading a Journal entry would not  
allow you in anyway to edit the remote users copy, you'd just get a  
snapshot downloaded to your Journal as if they had performed an  
equivalent Send to function.

 thought on wording, do you add more levels of sharing? Or do you just
 simplify the Share with: language language to Private, Share  
 with:
 Anyone.

 **though I would like entries to visually show their sharing state,  
 the
 buddy column hints at this but should be made explicit

 I do actually think that the Journal is the best place to expose this,
 especially since the way we plan to expose the feature in the UI is
 something like view my friend's Journal. I'm not sure exactly how
 or where that happens. Perhaps if we can abandon the checkbox for the
 multi-selection we can use that space for a public/private toggle of
 some kind.


My main reasons against the check-boxes are that they seem to eat  
quite a chunk of the UI, and make it seem a deal more visually  
complicated. I could imagine changing entry sharing status in the  
Journal details view, but that is out the way and not so scary for  
regular Journal use.

Regarding RSS feeds (which I do otherwise like for heterogeneous  
reasons), the main issue with that solution would be the problems when  
collaborators were using a remote Jabber server. Machines are likely  
behind firewalls et al, and accessing standard RSS feeds off such  
machines would fail in most cases requiring non standard network  
tweaks or alternative protocol support.

Regards,
--Gary

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

Re: [Sugar-devel] [Cs-dev] Sugar on a Stick - and OLPCsound

2009-07-03 Thread Art Hunkins

I've just noted that the /usr/lib/python2.6/site-packages folder does not 
include csnd.py. That folder also contains many fewer files that the 
corresponding one in python2.5.

As a matter of fact, python2.5 seems about a third the size of 2.6. Is all this 
correct?

Art Hunkins
  - Original Message - 
  From: Art Hunkins 
  To: pbrobin...@gmail.com 
  Sent: Friday, July 03, 2009 6:13 PM
  Subject: Fw: [Cs-dev] Sugar on a Stick - and OLPCsound


  Hello, Peter,

  Do you know what may be happening here? (Please see error log below.)

  I've no idea why the module referenced (csd.py) is not found. Please also 
compare the log at the very bottom of this mail; this latter log was generated 
when running Csound*5.08*, also with python2.6.

  Thanks for any insights.

  Art Hunkins

  - Original Message - 
  From: Art Hunkins 
  To: Developer discussions 
  Cc: cso...@lists.bath.ac.uk 
  Sent: Friday, July 03, 2009 5:36 PM
  Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound


  Here's the *next* chapter in the saga. Please note that this is not the 
*Windows* installation saga; it's the *Linux/Sugar* installation saga.

  In our last episode, we noted that Csound5.08 was (apparently?) incompatible 
with python2.6. At least this seemed a plausible explanation from the error log 
we saw.

  So, now Csound5.10 is available on Fedora(11) for download to SoaS.

  First, I try update csound; can't find any csound.
  Second, install csound; it tries, but then says, can't because it interferes 
with olpcsound (OK, different name!)
  Third, erase olpcsound; good
  Fourth, install csound; good

  Then I run my Activity; it now crashes with the similar, but not exact, error 
log below.

  I thought perhaps I'd better start from scratch and did (reformat USB drive, 
etc). Thought probably the new SoaS iso incorporated Csound5.10. But no, I 
needed to essentially repeat the above steps, and ended with the same crash.

  The log: (any new ideas please?)

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

  import sha

  Traceback (most recent call last):

  File /usr/bin/sugar-activity, line 21, in module

  main.main()

  File /usr/lib/python2.6/site-packages/sugar/activity/main.py, line 105, in 
main

  module = __import__(module_name) 

  File /home/liveuser/Activities/OurMusic.activity/ourmusic.py, line 41, in 
module

  import csndsugui

  File /home/liveuser/Activities/OurMusic.activity/csndsugui.py, line 36, in 
module

  import csnd

  ImportError: No module named csnd



  Art Hunkins

- Original Message - 
From: victor 
To: Art Hunkins ; Developer discussions 
Sent: Wednesday, July 01, 2009 1:36 PM
Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound


Because the 5.10 rpm has a python2.6 dependency. But that might
be the case for 5.08 too (I am not sure).
  - Original Message - 
  From: Art Hunkins 
  To: Developer discussions 
  Sent: Tuesday, June 30, 2009 2:22 AM
  Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound


  I just noticed that the current OLPC build includes Python 2.5, whereas 
SoaS includes Python 2.6

  Csound 5.08.91 is currently in both. Wouldn't this explain why 5.08.91 
doesn't work on SoaS? And why 5.10 should?

  Art Hunkins
- Original Message - 
From: victor.lazzar...@nuim.ie 
To: Developer discussions 
Sent: Monday, June 29, 2009 5:38 PM
Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound


The message is strange, but it does not say there is a Python
version mismatch. However, having said that, the 5.08.91
rpm was built with 2.5 (unless what you have there is another
build that somehow uses 2.6). 

What the message says is that the library module Python
tried to load does not have one of the API functions. The
reason for this I don't know.

Victor

- Original Message -
From: Art Hunkins abhun...@uncg.edu
Date: Monday, June 29, 2009 10:19 pm
Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound
To: csound-de...@lists.sourceforge.net

 Victor, Brian and Mike G. -
 
 I'd like to ask again regarding this SoaS log, and what it 
 suggests about 
 the crash of my OurMusic activity.
 
 The version of Csound is 5.08.91, libsndfile is 1.0.17. And as 
 you can see 
 Python 2.6 and libcsnd.so.5.1 are referenced in the log.
 
 Is the difficulty incompatible versions of Python and/or 
 libsndfile/libcsnd.so.5.1?
 
 A member of the sugar-devel list suggested that the problem 
 might well be 
 solved with Csound5.10 (Fedora 11) which will be available 
 through yum 
 update later this week. (It's apparently ready

Re: [Sugar-devel] Gitorious problems

2009-07-03 Thread Jim Simmons

Bastien,

For what it's worth, here is my config file for read etexts:

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote origin]
url = gitori...@git.sugarlabs.org:readetexts/mainline.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch master]
remote = origin
merge = refs/heads/master

Hope this helps.

James Simmons

 Date: Fri, 03 Jul 2009 17:58:50 +0200
 From: Bastien bastiengue...@googlemail.com
 Subject: Re: [Sugar-devel] How to create a project on SugarLabs
        gitorious?
 To: Luke Faraone l...@faraone.cc
 Cc: sugar-devel@lists.sugarlabs.org
 Message-ID: 8763e992rp@bzg.ath.cx
 Content-Type: text/plain; charset=us-ascii

 Luke Faraone l...@faraone.cc writes:

 On Thu, Jul 2, 2009 at 06:13, Bastien bastiengue...@googlemail.com wrote:

     Bastien b...@laptop.org writes:

      See this wiki page: http://wiki.sugarlabs.org/go/Activity_Team/Git_FAQ
     
      That's it, thanks.

     I have uploaded my id_dsa.pub key on my account.

 Please try again with RSA, use of DSA is discouraged.

 Thanks.

 I had both DSA and RSA keys on gitorious.  I deleted the DSA key.
 I still get this annoying error:

 ,
 | Access denied or bad repository path
 | fatal: The remote end hung up unexpectedly
 `

 My email on .gitconfig and gitorious are the same.  I have this error
 from several IP addresses, so I guess I'm not blacklisted.

 Here is my ~/Activities/Helpfr.activity/.git/config file:

 ,
 | [core]
 |       repositoryformatversion = 0
 |       filemode = true
 |       bare = false
 |       logallrefupdates = true
 | [remote origin]
 |       url = gitori...@git.sugarlabs.org:helpfr/mainline.git
 |       fetch = +refs/heads/*:refs/remotes/origin/*
 | [push]
 |       default = matching
 `

 Any other idea?

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

[Sugar-devel] Get Internet Archive Books Activity source code

2009-07-03 Thread Jim Simmons

Version 2 of Get Internet Archive Books was released this morning.  I
like this one a lot better than my first effort; it should be good
enough to use, not just criticize.  I have put the source code tar.bz
on shell.sugarlabs.org in /upload/honey/GetIABooks, for anyone wanting
to package it up for distributions.

Thanks,

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

Re: [Sugar-devel] [Cs-dev] Sugar on a Stick - and OLPCsound

2009-07-03 Thread Martin Dengler

On Fri, Jul 03, 2009 at 07:57:37PM -0400, Art Hunkins wrote:

 I've just noted that the /usr/lib/python2.6/site-packages folder
 does not include csnd.py.

Given that csnd.py was there before you erased olpcsound, and after
you erased olpcsound it was gone, I suspected that olpcsound is what
installs csnd.py.  A quick rpm -q --whatprovides
/usr/lib/python2.6/site-packages/csnd.py confirmed this.

 Art Hunkins

Martin

PS - I realise this isn't the most helpful answer to your
question...more research is necessary but I suspect going back to the
original error would be helpful.



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

Re: [Sugar-devel] Journal feature request--more data in main display

On Fri, Jul 03, 2009 at 06:29:21PM +0100, Gary C Martin wrote:
 On 3 Jul 2009, at 05:53, Aleksey Lim wrote:

 On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote:
 * additional types of filters
  for example Library has[2] several types to filter objects

  * user tags
  * object traits(additional columns from previous section) like  
 author,
genre, date for books
  * activity creators(grouping by activity_id field)
  * types of objects(like top section in filter palette)[3]
  * filter by participants
  * filter by sources(if we are in shared mode)

  I'm not sure that all of these modes are useful, but something could
  be(or another types)

 like http://wiki.sugarlabs.org/go/File:-5.png

 The filters (currently in Journal, and in my mock-ups) are in separate  
 top level toolbar controls. I'm basically just switching them to icons  
 instead of text menus. From your mock-up, User tags would be  
 controlled via a palette (not yet finished the mock-up) from that tag/ 
 label icon shown in the toolbar. Next to it will also be added a buddy  
 icon (white outline) for a filter palette (not yet finished the mock-up) 
 that looks like it would cover Participants.

 Where you have Object types I understand that as file mime types,  
 which was what I placed at the top of that palette before your mock-up  
 modification :-)

 Your Object traits I thing a best just dealt with in a universal way  
 as tags, no new ontology needed and gets to benefit from any general tag 
 improvements we make to Sugar (details entry, activity naming dialogue 
 improvements, auto completion, 'tags under title' Journal entry display, 
 the Object Chooser).

 I'm not convinced I understand your Creators category. Is this  
 original author, the Activity used to build the entry, or something  
 else?

its just grouping my activity_id DS field


 Regards,
 --Gary


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

Re: [Sugar-devel] How to create a project on SugarLabs gitorious?

Hi Bastien,

H, I might well be confused here, but looking at gitiorus I see no  
helpfr project for you to push to:

http://git.sugarlabs.org/projects/helpfr

You need to login, click Projects in the top right, then New  
project in the left, and create your project. Once created, if you  
navigate to your projects mainline page, at the top it lists example  
clone and push commands for your project i.e. you should be able to  
push with something like:

git push gitori...@git.sugarlabs.org:helpfr/mainline.git

If you think you have done this already, login and click Dashboard  
to show projects you have created and double check helpfr is listed  
there (I couldn't find this project name via searc or manually  
mangling URLs to where it should be).

Hope that's of some help!

Regards,
--Gary

On 3 Jul 2009, at 16:58, Bastien wrote:

 Luke Faraone l...@faraone.cc writes:

 On Thu, Jul 2, 2009 at 06:13, Bastien  
 bastiengue...@googlemail.com wrote:

Bastien b...@laptop.org writes:

 See this wiki page: http://wiki.sugarlabs.org/go/Activity_Team/Git_FAQ

 That's it, thanks.

I have uploaded my id_dsa.pub key on my account.

 Please try again with RSA, use of DSA is discouraged.

 Thanks.

 I had both DSA and RSA keys on gitorious.  I deleted the DSA key.
 I still get this annoying error:

 ,
 | Access denied or bad repository path
 | fatal: The remote end hung up unexpectedly
 `

 My email on .gitconfig and gitorious are the same.  I have this error
 from several IP addresses, so I guess I'm not blacklisted.

 Here is my ~/Activities/Helpfr.activity/.git/config file:

 ,
 | [core]
 | repositoryformatversion = 0
 | filemode = true
 | bare = false
 | logallrefupdates = true
 | [remote origin]
 | url = gitori...@git.sugarlabs.org:helpfr/mainline.git
 | fetch = +refs/heads/*:refs/remotes/origin/*
 | [push]
 | default = matching
 `

 Any other idea?

 -- 
 Bastien
 ___
 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] Get Internet Archive Books Activity source code

Hi James,

On 4 Jul 2009, at 01:25, Jim Simmons wrote:

 Version 2 of Get Internet Archive Books was released this morning.  I
 like this one a lot better than my first effort; it should be good
 enough to use, not just criticize.  I have put the source code tar.bz
 on shell.sugarlabs.org in /upload/honey/GetIABooks, for anyone wanting
 to package it up for distributions.

Cool :-) Have it downloaded already but no time to play ( read) yet.  
Will take a look over the weekend and give it a good spin!

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

[Sugar-devel] [server-devel] Setting up the XS

2009-07-03 Thread Vamsi Krishna Davuluri

Hi,

So as per Martin's suggestion. I'm making this mail.

I don't have a spare system at my disposal right now,
so I am running XS under a VM.
But I can't figure out how to access the moodle server
outside the VM. (virtual Box)
Other than that moodle is set up.

Thanks,

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

Re: [Sugar-devel] [server-devel] Setting up the XS

2009-07-03 Thread Dave Bauer

On Fri, Jul 3, 2009 at 9:05 PM, Vamsi Krishna Davuluri 
vamsi.davul...@gmail.com wrote:

 Hi,

 So as per Martin's suggestion. I'm making this mail.

 I don't have a spare system at my disposal right now,
 so I am running XS under a VM.
 But I can't figure out how to access the moodle server
 outside the VM. (virtual Box)
 Other than that moodle is set up.


This depends on how you have setup the virtual network adapters.

How many did you setup and what technique did you use, Bridged, NAT,
Internal for each one?

Also if you execute ifconfig from the terminal within the XS VM what is
the output?  This should show what addresses the interfaces are listening
on.

I just had another idea.

netstat -an | grep 80

should tell you which IP address the Moodle server is listening on. It is on
port 80. You'll also see port 8080 for the idmgr service.

Dave



 Thanks,

 Vamsi

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




-- 
Dave Bauer
d...@solutiongrove.com
http://www.solutiongrove.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

2009-07-03 Thread Andrés Ambrois

On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote:
 On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote:
  On 2 Jul 2009, at 14:47, Eben Eliason wrote:
  On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org 
wrote:
  But in that case we should provide possibility to mark objects that can
  be shared(I guess sharing all local objects by default is not a nice
  idea).
 
  Right. This would be essential. There's definitely some thought that
  needs to be done here.
 
  Scott had an interesting proposal which basically exposed the Journal
  (or some subset of it) as an RSS feed. This was really neat, because
  it meant we could build a UI for someone else's Journal in Sugar,
  populating it with that data, but also that these feeds could be
  shared globally, for anyone with an RSS reader to benefit from. That's
  a really powerful approach in my mind, and there is some starter code
  lying around as a proof of concept already!
 
  +1 to rss feed concept, makes life a lot easier in a heterogeneous
  environment.
 
  I'm still catching up on email so apologies if this has been mentioned
  already. But the UI for marking of entries as sharable does not
  necessarily need to be another Journal user-interface addition** In the
  simplest approach you could just extend the Activity Share with: my
  Neighbourhood control to mark a Journal entry as part of the RRS feed.
  Would need some

 The problem I see with this is that we're talking about two different
 kinds of sharing. Just because I want to make a picture I drew
 available for anyone to look at, or even make a photocopy of to
 scribble on, doesn't mean that I want to let them into a shared
 painting session so they can scribble on the original with me.

 This is the difference between sharing an activity with someone
 collaboratively, and sending them (a copy of) the resulting object.

  thought on wording, do you add more levels of sharing? Or do you just
  simplify the Share with: language language to Private, Share with:
  Anyone.
 
  **though I would like entries to visually show their sharing state, the
  buddy column hints at this but should be made explicit

 I do actually think that the Journal is the best place to expose this,
 especially since the way we plan to expose the feature in the UI is
 something like view my friend's Journal. I'm not sure exactly how
 or where that happens. Perhaps if we can abandon the checkbox for the
 multi-selection we can use that space for a public/private toggle of
 some kind.

How about using special tags? A Publish tag seems reasonable for this, and 
consistent with the fact that it could live in a publish directory an HTTP 
server would serve. 

I can also imagine a tags used for starred entries and other metadata (in a 
general sense) used by sugar. This would make them searchable as well. 


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

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

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

On Fri, Jul 3, 2009 at 7:25 PM, Gary C Marting...@garycmartin.com wrote:
 On 3 Jul 2009, at 23:50, Gary C Martin wrote:

 On 3 Jul 2009, at 18:29, Eben Eliason wrote:

 On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com
 wrote:

 On 2 Jul 2009, at 14:47, Eben Eliason wrote:

 On Wed, Jul 1, 2009 at 1:42 PM, Aleksey
 Limalsr...@member.fsf.org wrote:

 But in that case we should provide possibility to mark objects
 that can
 be shared(I guess sharing all local objects by default is not a
 nice
 idea).

 Right. This would be essential. There's definitely some thought that
 needs to be done here.

 Scott had an interesting proposal which basically exposed the
 Journal
 (or some subset of it) as an RSS feed. This was really neat, because
 it meant we could build a UI for someone else's Journal in Sugar,
 populating it with that data, but also that these feeds could be
 shared globally, for anyone with an RSS reader to benefit from.
 That's
 a really powerful approach in my mind, and there is some starter
 code
 lying around as a proof of concept already!


 +1 to rss feed concept, makes life a lot easier in a heterogeneous
 environment.

 I'm still catching up on email so apologies if this has been
 mentioned
 already. But the UI for marking of entries as sharable does not
 necessarily
 need to be another Journal user-interface addition** In the simplest
 approach you could just extend the Activity Share with: my
 Neighbourhood
 control to mark a Journal entry as part of the RRS feed. Would need
 some

 The problem I see with this is that we're talking about two different
 kinds of sharing. Just because I want to make a picture I drew
 available for anyone to look at, or even make a photocopy of to
 scribble on, doesn't mean that I want to let them into a shared
 painting session so they can scribble on the original with me.

 This is the difference between sharing an activity with someone
 collaboratively, and sending them (a copy of) the resulting object.

 Devils advocate here, so just because someone was late to the realtime
 party, they don't get to download an otherwise openly published piece
 of work that could be re-published at any time by any of the
 temporally lucky contributors? Downloading a Journal entry would not

I think you misunderstand me, as I think I'm arguing exactly the
opposite. I wouldn't want to deprive people the ability to download
finished works because the sharer doesn't want to open the document up
for public collaboration. The distinction is important, so that it's
possible to share things with others without having to make my own
documents open to collaboration.

 allow you in anyway to edit the remote users copy, you'd just get a
 snapshot downloaded to your Journal as if they had performed an
 equivalent Send to function.

Exactly. If you conflate public vs. private states for documents with
the collaboration sharing scope, every public document would also be
open for public collaboration, which might not be desired, and might
discourage people from sharing their output.

 Replying to myself, always a bad sign ;-)

 Use case: Darn, I missed the weekly project chat meeting, AGAIN... Oooh,
 Bob is still online, let me see if I can download the meeting activity
 entry.

This might not be the best example, since by definition the chat
meeting is an open collaboration, with a neighborhood (for example)
sharing scope.

 Misc supporting argument: If you default to Journal sharing OFF and make it
 a new separate manual public sharing UI tick box/setting (required for

I'm not necessarily stating that it should be off by default
(everything private). I'm simply arguing that it should be independent
of the collaboration scope. What may make sense (maybe this is what
you meant?) is to default all documents which become shared with the
neighborhood to public, while all others would default to private.

Eben

PS. I think we need to come up with some better terminology to
distinguish between collaboration sharing and journal sharing. That
would make this much easier to talk about.


 privacy), folks will rarely set it, there will be little to share from
 someone else's Journal so you'll rarely bother looking for something
 remotely. Changing the Activity sharing language from Share with:
 Neighbourhood to Share with: Anyone, means both synchronous and
 asynchronous sharing could happen, suddenly allows deployments to
 automatically** cross pollinate content and activities as folks move from
 otherwise isolated network islands.

 **by automatically, I mean that the sharer has not needed to be asked to
 provide specific access to some entry, if it already was public, then it is
 shared. Though this does suggest to me that we should finally be allowed to
 un-publicly share an entry if desired (a manual choice); and perhaps a
 global manual setting for deployments/users to switch of all Journal
 sharing.

 Regards,
 --Gary


___

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

On Fri, Jul 3, 2009 at 9:52 PM, Andrés Ambroisandresambr...@gmail.com wrote:
 On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote:
 On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote:
  On 2 Jul 2009, at 14:47, Eben Eliason wrote:
  On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org
 wrote:
  But in that case we should provide possibility to mark objects that can
  be shared(I guess sharing all local objects by default is not a nice
  idea).
 
  Right. This would be essential. There's definitely some thought that
  needs to be done here.
 
  Scott had an interesting proposal which basically exposed the Journal
  (or some subset of it) as an RSS feed. This was really neat, because
  it meant we could build a UI for someone else's Journal in Sugar,
  populating it with that data, but also that these feeds could be
  shared globally, for anyone with an RSS reader to benefit from. That's
  a really powerful approach in my mind, and there is some starter code
  lying around as a proof of concept already!
 
  +1 to rss feed concept, makes life a lot easier in a heterogeneous
  environment.
 
  I'm still catching up on email so apologies if this has been mentioned
  already. But the UI for marking of entries as sharable does not
  necessarily need to be another Journal user-interface addition** In the
  simplest approach you could just extend the Activity Share with: my
  Neighbourhood control to mark a Journal entry as part of the RRS feed.
  Would need some

 The problem I see with this is that we're talking about two different
 kinds of sharing. Just because I want to make a picture I drew
 available for anyone to look at, or even make a photocopy of to
 scribble on, doesn't mean that I want to let them into a shared
 painting session so they can scribble on the original with me.

 This is the difference between sharing an activity with someone
 collaboratively, and sending them (a copy of) the resulting object.

  thought on wording, do you add more levels of sharing? Or do you just
  simplify the Share with: language language to Private, Share with:
  Anyone.
 
  **though I would like entries to visually show their sharing state, the
  buddy column hints at this but should be made explicit

 I do actually think that the Journal is the best place to expose this,
 especially since the way we plan to expose the feature in the UI is
 something like view my friend's Journal. I'm not sure exactly how
 or where that happens. Perhaps if we can abandon the checkbox for the
 multi-selection we can use that space for a public/private toggle of
 some kind.

 How about using special tags? A Publish tag seems reasonable for this, and
 consistent with the fact that it could live in a publish directory an HTTP
 server would serve.

I think it's a good idea to store these states as metadata, but I also
think that we need to expose the feature visually to highlight the
capability and make it easier to manage. I wouldn't want kids to have
to type publish into the correct field in order to share their work.

 I can also imagine a tags used for starred entries and other metadata (in a
 general sense) used by sugar. This would make them searchable as well.

Yup. I don't think this works yet, but the intent has always been to
allow advanced search queries by specifying key:value pairs (as in
gmail). In fact, all of the filters we support should have text
equvalents, eg. cat kind:image with:alice favorite:yes (or similar).

Eben


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

 --
  -Andrés

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

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

On Fri, Jul 3, 2009 at 2:05 PM, Aleksey Limalsr...@member.fsf.org wrote:
 On Fri, Jul 03, 2009 at 01:29:56PM -0400, Eben Eliason wrote:
 On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote:
  On 2 Jul 2009, at 14:47, Eben Eliason wrote:
 
  On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote:
 
  But in that case we should provide possibility to mark objects that can
  be shared(I guess sharing all local objects by default is not a nice
  idea).
 
  Right. This would be essential. There's definitely some thought that
  needs to be done here.
 
  Scott had an interesting proposal which basically exposed the Journal
  (or some subset of it) as an RSS feed. This was really neat, because
  it meant we could build a UI for someone else's Journal in Sugar,
  populating it with that data, but also that these feeds could be
  shared globally, for anyone with an RSS reader to benefit from. That's
  a really powerful approach in my mind, and there is some starter code
  lying around as a proof of concept already!
 
 
  +1 to rss feed concept, makes life a lot easier in a heterogeneous
  environment.
 
  I'm still catching up on email so apologies if this has been mentioned
  already. But the UI for marking of entries as sharable does not necessarily
  need to be another Journal user-interface addition** In the simplest
  approach you could just extend the Activity Share with: my Neighbourhood
  control to mark a Journal entry as part of the RRS feed. Would need some

 The problem I see with this is that we're talking about two different
 kinds of sharing. Just because I want to make a picture I drew
 available for anyone to look at, or even make a photocopy of to
 scribble on, doesn't mean that I want to let them into a shared
 painting session so they can scribble on the original with me.

 This is the difference between sharing an activity with someone
 collaboratively, and sending them (a copy of) the resulting object.

  thought on wording, do you add more levels of sharing? Or do you just
  simplify the Share with: language language to Private, Share with:
  Anyone.
 
  **though I would like entries to visually show their sharing state, the
  buddy column hints at this but should be made explicit

 I do actually think that the Journal is the best place to expose this,
 especially since the way we plan to expose the feature in the UI is
 something like view my friend's Journal. I'm not sure exactly how
 or where that happens. Perhaps if we can abandon the checkbox for the
 multi-selection we can use that space for a public/private toggle of
 some kind.

 so, you think that my idea of Pins looks ugly :)
 http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016025.html

Something like that could work. Pins, icons, iconic tags: any of these
variants on the idea could work. Perhaps we can find a way to
integrate these into the line of tags, at the beginning before the
custom tags, instead of eating up extra space to the left of each
entry. However, I do think we'll probably want to make these basic
toggles permanent so that they are visually on or off and can't ever
disappear completely for an entry, so that it's obvious that they
exist and they are easy to toggle.

Eben


 --
 Aleksey

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

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

2009-07-03 Thread Andrés Ambrois

On Friday 03 July 2009 11:18:24 pm Eben Eliason wrote:
 On Fri, Jul 3, 2009 at 9:52 PM, Andrés Ambroisandresambr...@gmail.com 
wrote:
  On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote:
  On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com 
wrote:
   On 2 Jul 2009, at 14:47, Eben Eliason wrote:
   On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org
 
  wrote:
   But in that case we should provide possibility to mark objects that
   can be shared(I guess sharing all local objects by default is not a
   nice idea).
  
   Right. This would be essential. There's definitely some thought that
   needs to be done here.
  
   Scott had an interesting proposal which basically exposed the Journal
   (or some subset of it) as an RSS feed. This was really neat, because
   it meant we could build a UI for someone else's Journal in Sugar,
   populating it with that data, but also that these feeds could be
   shared globally, for anyone with an RSS reader to benefit from.
   That's a really powerful approach in my mind, and there is some
   starter code lying around as a proof of concept already!
  
   +1 to rss feed concept, makes life a lot easier in a heterogeneous
   environment.
  
   I'm still catching up on email so apologies if this has been mentioned
   already. But the UI for marking of entries as sharable does not
   necessarily need to be another Journal user-interface addition** In
   the simplest approach you could just extend the Activity Share with:
   my Neighbourhood control to mark a Journal entry as part of the RRS
   feed. Would need some
 
  The problem I see with this is that we're talking about two different
  kinds of sharing. Just because I want to make a picture I drew
  available for anyone to look at, or even make a photocopy of to
  scribble on, doesn't mean that I want to let them into a shared
  painting session so they can scribble on the original with me.
 
  This is the difference between sharing an activity with someone
  collaboratively, and sending them (a copy of) the resulting object.
 
   thought on wording, do you add more levels of sharing? Or do you just
   simplify the Share with: language language to Private, Share
   with: Anyone.
  
   **though I would like entries to visually show their sharing state,
   the buddy column hints at this but should be made explicit
 
  I do actually think that the Journal is the best place to expose this,
  especially since the way we plan to expose the feature in the UI is
  something like view my friend's Journal. I'm not sure exactly how
  or where that happens. Perhaps if we can abandon the checkbox for the
  multi-selection we can use that space for a public/private toggle of
  some kind.
 
  How about using special tags? A Publish tag seems reasonable for this,
  and consistent with the fact that it could live in a publish directory an
  HTTP server would serve.

 I think it's a good idea to store these states as metadata, but I also
 think that we need to expose the feature visually to highlight the
 capability and make it easier to manage. I wouldn't want kids to have
 to type publish into the correct field in order to share their work.

I wasn't suggesting that either. Scott's concepts [0] have a list of used tags 
for exploration, these special tags would be highlighted/prioritized somehow 
in this list. 

[0]http://wiki.laptop.org/go/Image:Journal2-working.png


  I can also imagine a tags used for starred entries and other metadata (in
  a general sense) used by sugar. This would make them searchable as well.

 Yup. I don't think this works yet, but the intent has always been to
 allow advanced search queries by specifying key:value pairs (as in
 gmail). In fact, all of the filters we support should have text
 equvalents, eg. cat kind:image with:alice favorite:yes (or similar).

 Eben

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

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

Re: [Sugar-devel] Journal feature request--more data in main display

On Fri, Jul 3, 2009 at 2:17 PM, Gary C Marting...@garycmartin.com wrote:
 On 3 Jul 2009, at 10:01, Martin Langhoff wrote:

 On Fri, Jul 3, 2009 at 5:29 AM, Gary C Marting...@garycmartin.com wrote:

 Aleksey was keen to see any Journal mock-up work in progress I had,
 early as possible, so here's where I'm at :-) There's plenty to do
 still, images are intended to help bounce ideas about, poke at the
 grey matter between our ears, and get a feel for how things could (or
 not) be done:


 http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes

 Very cool. I do agree the filter is very culture-dependent.

 On a similar vein, the 'tag' icon has no visual association with the
 many tags on screen. If they had a similar shape, then it'd be easy to
 connect, for users who don't recognise a tag and the (somewhat odd)
 use of tag to mean a bit of metadata on a digital resource.

 I just 'acquired' the tag/label icon from Eben's mock-ups. Assume he had
 though about this way more than me :-) Sure there are plenty of revisions,
 reworks, and cherry picking.

Heh, you did. Nice. Did those mockups show how we might show the tags
themselves in the UI, though? I do think it's important to make the
label reflect the UI. That said, I'm actually thinking that the tag
dropdown should be an extension of the search field itself. Perhaps
it's just to the right, and only needs to be a little down arrow that
reveals the tags (or perhaps we even modify the search entry to have
this button). Previous mockups I'd worked on were based on the idea
that a tag suggestion window would popup beneath the search field
while typing to show possible tags. The thought for the explicit
dropdown arrow would be to choose tags without having to start typing.

 Wishlist: show files by size filter or option? If the Uruguay
 experience is any indicator, a fact of life is that users after all
 *will* hit:

Yes, exposing size in the main list might be worth considering.

 - problems with fitting files (large and small) in USB disks

 - problems with their Journal taking too much space

 - problems with installed Activities taking too much disk space

 Good point! Though arbitrary Journal sorting likely breaks many design
 goals***, otherwise you'd have thought we would have the most basic of
 features, sort by creation date, by now ;-) At the very least size taken by
 an entry should be visible on the details view. Right now there is zero
 indication other than just watching your total Journal grow in size via it's
 frame icon.

 ***Eben can you clarify this one? If locking folks into a 'view Journal only
 by modification date' was an intentional design choice?

Not at all. The proposed designs include a sort bar, which would
function in the traditional fashion, but be sorted by date (when) by
default. See http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#03

Tomeu has been working on using the standard GTK TreeView, so I think
we're on track to add sorting by name, date, and participants (we need
to decide what sorting by participants means...I think sorting by
number of participants might be the useful choice, so that it's easy
to surface the collaborative activities). If we expose file size in
this list somehow, that would also be sortable.

Eben

 Regards,
 --Gary

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

Re: [Sugar-devel] ActivityTeam meeting on Friday June 26th - 17:00 UTC

On 3 Jul 2009, at 05:12, S Page wrote:

 On Thu, Jul 2, 2009 at 8:04 PM, David  
 Farningdfarn...@sugarlabs.org wrote:

 Maybe.  Stand back, what the heck is Activities/All for?  I marked  
 the
 page obsolete and nobody has disagreed. ...

 Someone disagreed quite enthusiastically the other day.  Their
 rational was that deployments still refer to /All as their primary
 download page.

 Are you referring to Gabriel Eirea's message
 http://lists.sugarlabs.org/archive/sugar-devel/2009-June/015446.html ?

Yes that's one recent account, but I must admit at the time I was  
confused suddenly changed also (as an Activity developer wondering  
where everything had gone). I'm sure we had a number of list/support  
emails about it at the time of the change. Now that you mention that  
the updater has some fallback hooks for the 
http://wiki.laptop.org/go/Activities 
  I can understand the change from a technical stand point (seemed  
random and arbitrary at the time).

I think the issue was that the page was very visual, all those  
activity icons, you'd just hit the URL and scroll direct to the stuff  
you want. All that up top text is usually just skipped and you'd never  
notice an extra paragraph or sentence on a revisit – at least that was  
my behaviour – I'm still not sure I've read it as I automatically  
assume I know what is says :-) Just forcing myself to read it now ;-)

Oooh my, so the link to Activities/All has been removed already!  
(though I note there is still link to Activities/Other page which  
seems an even more Bohemian and un-maintained collection).

It's going to take a while to get all Activities/All content over to  
SL infrastructure (at least the stuff we have the energy and time to  
save from the jaws of obscurity and bit rot)... I can work from the  
old All page fine still, just hope existing users see and understand  
the text at the top of the page and make it over to  
activities.sugarlabs.org.

Any authors/developers/coders who could adopt an orphaned Activity,  
and help migrate it over to Sugar Labs infrastructure? There's lots of  
valuable Activities still there that could do with some love:

http://wiki.laptop.org/go/Activities/All

The Sugar Labs ActivityTeam pages had documentation on the migration  
process:

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

I'll keep on cherry picking at this, but my time is limited.

Regards,
--Gary

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

Re: [Sugar-devel] [Cs-dev] Sugar on a Stick - and OLPCsound

2009-07-03 Thread Art Hunkins

That seems to make sense.

My problem was that I had to erase olpcsound before it was possible to 
install csound - as csound conflicted with olpcsound. Perhaps the name 
change was the real issue; if both had been named csound, I could simply 
have done a csound update.

At least that's an idea. The *original* situation found csnd.py, but then 
failed with _csnd - not finding a requested variable.

Art Hunkins

- Original Message - 
From: Martin Dengler mar...@martindengler.com
To: Art Hunkins abhun...@uncg.edu
Cc: pbrobin...@gmail.com; cso...@lists.bath.ac.uk; 
sugar-devel@lists.sugarlabs.org
Sent: Friday, July 03, 2009 8:46 PM
Subject: Re: [Sugar-devel] [Cs-dev] Sugar on a Stick - and OLPCsound


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

[Sugar-devel] issues showing Activities for OLPC 8.2.x from a.sl.o.

2009-07-03 Thread S Page

I want a long-lived URL that will list activities on
activities.sugarlabs.org that work on XO-1's running release 8.2.x,
and I'm confused on several points.

* Should I filter by Refine Results Compatible with 0.82 , or by
choosing Advanced search Platform: OLPC Software Release 8.2.0
(Build 767), or both?

* Refining results to 0.82 or choosing Sugar version 0.82 reduces the
results returned from 157 to 138, but choosing Platform: OLPC Software
Release 8.2.0 (Build 767) does nothing. That doesn't make any sense,
implicitly OLPC 8.2.0 *is* Sugar version 0.82 (or, technically,
0.82.1).

* I'm pretty sure the filtering on version is broken. Etoys, Read,
and Terminal seem to offer the same download regardless of version,
but I believe they have different versions for 8.2.x and later
Sucrose.
Filtering for 0.82 only seems to exclude experimental downloads like
APRS, Bundle, Frotz, etc.

* In Advanced search Platform, there's no choice for the latest OLPC
version, OLPC 8.2.1 (Build 802). Maybe the Platform option should be
OLPC Software Release 8.2.x , and leave out Build 767 ?

* In the Advanced search dialog, having Sugar Platform version and
Platform is confusing. I think leave Platform out of Sugar
version.

* The feedback in search results if you use Advanced is poor. It
doesn't show what advanced search constraints are on (they could be
given after the text Showing 1 - 20 of 157 results for Platform: xxx
and versions: NN. Sometimes the page seems to forget what you've
chosen, and sometimes refining results to limit to 0.82 doesn't change
the count.

* Using Browse in 8.2.1 on XO-1 and Firefox on a desktop, the Browse
version offered to me has a clipped
Download Now (OLPC Software Release 8.2.0 #40;Build 767#41;)
button, only Download Now (OLPC ... is visible. I guess the #40;
and #41 are the '(' and ')' from the platform. I filed
http://dev.sugarlabs.org/ticket/1020

* How is a.sl.o knowing to offer this Browse version to me? It and
Software to work with scales and chords on musical instruments. are
the only activities that have this Download Now (OLPC... button.

Aleksey Sim wrote
* New ASLO check user agent string for SugarPlatform version in format:
Sugar Labs/major-version.minor-version
for example Sugar Labs/0.84 and add hints to download button
* How do I know if this check is in place?
* It seems both my browsers offer me Browse version
http://activities.sugarlabs.org/en-US/sugar/downloads/latest/4024/platform:7/addon-4024-latest.xo
, does platform:7 in the URL indicate the the OLPC Software Release
version?

* I want to compare the activity versions that a.sl.o offers for OLPC
8.2.0 / Sugar 0.82 with the versions splattered all over
wiki.laptop.org. Is there a way to get a.sl.o to return results in
some other format, like text or an XML structure?

Many thanks, I hope my comments are useful.
Who thought of using the addons.mozilla.org codebase for a.sl.o?
Stroke of genius!
--
=S Page
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Journal feature request--more data in main display

On Fri, Jul 3, 2009 at 1:57 PM, Aleksey Limalsr...@member.fsf.org wrote:
 On Fri, Jul 03, 2009 at 06:13:24PM +0100, Gary C Martin wrote:
 Hi Aleksey,

 On 3 Jul 2009, at 05:25, Aleksey Lim wrote:
 On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote:
 Aleksey was keen to see any Journal mock-up work in progress I had,
 early as possible, so here's where I'm at :-) There's plenty to do
 still, images are intended to help bounce ideas about, poke at the
 grey
 matter between our ears, and get a feel for how things could (or
 not) be
 done:

     
 http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes

 Some thoughts:

 * what about adding ultra compact list view for objects(not actions)
  like list view in Library[1]
  the purpose is, if user has lots of objects it could be useful idea
 to
  show as much as possible objects on one screen

I prefer to keep the activity icons always at a constant size. We
played around with smaller lists for the reason you suggest, but we
didn't feel that the resulting designs were suitable for kids, both
because the fonts and icons were smaller and harder to read, and
because the clickable targets were so much smaller.

 We do want to show plenty of entries, but need to keep in mind visible
 size of each text/icon row entry. My current call is to make each
 Journal entry row 'richer' rather than trying to cram on more rows
 (encourage folks to search/filter down to a small number of results).

I think this is the right approach.

 Maybe having several views/layouts(for several purposes) is more useful
 idea then only one common view for all purposes?  I mean:

 * compact view
  could be not trivial(horizontal scrolls) but highly
  configured(show/hide columns)
  for people who want narrow lines with additional columns
  (to sort them for example)
 * grid view
  and use filters to show what user needs(because there could a lack
  of useful info in this view)

 The grid view is better for looking and scrubbing through many entries.
 In Library you've made your rows richer by adding many more options for
 showing extra columns of information (author, artist, date, album, disk,
 track, genre, copyright, ...) at the cost of lots of horizontal
 scrolling, and option complexity.

  * having several column/grid layouts
    for example its very useful for books to have columns for author,
    genre, date; so, user can see the whole valuable info at once and
 sort
    objects by these columns; and so separate layouts for video audio
    etc. files

I think it's far better to have custom activities for these types of
use cases. I think the Journal should be a really powerful tool for
locating this kind of information, but adding lots of complicated
views for various formats which kids may or may not even have lots of
could easily add needless complexity. I think we should focus on
making the best all-purpose solution.

I'll throw this idea back out there for fun, too. I don't  know if
there's a way to do even this without adding too much complexity, but
we did make some mockups of an advanced sort bar, which instead of
sorting on columns allowed creation of hierarchical sorting by
metadata. For example, I could use the what filter to select audio
files, and then use the sort bar to say: sort by artist, then by
album, then by track. Any Journal entries which had metadata keys for
artist, album, and track would then appear sorted accordingly,
and the section dividers would show the values for the various keys so
that the hierarchy was logically browsable.

It's a powerful idea, but so far we just haven't thought it to be
worth the added complexity. Keeping the Journal as simple to use as
possible is paramount.

 The option complexity is too high for me, and causes horizontal
 scrolling (mentioned above), though the ability to sort on any arbitrary

I think we should avoid horizontal scrolling at all costs. Not only is
it a nuisance, but I like the logical mapping the scrolling axis to
time (or, I suppose, to whatever sort is selected).

 column is a bonus. Personally I think all the extra column information
 would be much better treated as tags, that way you can use the existing
 Journal tagging mechinisum, search and drill down to the entries you are
 after, and with the title + tag row entry still get to directly browse
 that information if needed.

Yup. I think we can make the search and tagging even more powerful by
supporting user created metadata as well. This is obviously an
advanced feature, but that's OK with me since it doesn't get in the
way of basic use. Typing in key:value pairs into the tag field should
provide searchable keys. In this manner, it should be possible to do
searches for color:red to match only on entries which have the value
red for the key color, instead of all entries which had the tag
red, or the word red in their titles, etc.

 * additional types of filters
  for example Library has[2] several types to filter objects

 As

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting


On 4 Jul 2009, at 03:13, Eben Eliason wrote:
 On Fri, Jul 3, 2009 at 7:25 PM, Gary C Marting...@garycmartin.com  
 wrote:
 Devils advocate here, so just because someone was late to the  
 realtime
 party, they don't get to download an otherwise openly published  
 piece
 of work that could be re-published at any time by any of the
 temporally lucky contributors? Downloading a Journal entry would not

 I think you misunderstand me, as I think I'm arguing exactly the
 opposite. I wouldn't want to deprive people the ability to download
 finished works because the sharer doesn't want to open the document up
 for public collaboration. The distinction is important, so that it's
 possible to share things with others without having to make my own
 documents open to collaboration.

OK, yes thanks, I see this issue now: I might want folks to be able to  
download an entry, but I might well want to work on it privately, by  
myself.

 allow you in anyway to edit the remote users copy, you'd just get a
 snapshot downloaded to your Journal as if they had performed an
 equivalent Send to function.

 Exactly. If you conflate public vs. private states for documents with
 the collaboration sharing scope, every public document would also be
 open for public collaboration, which might not be desired, and might
 discourage people from sharing their output.

Yep.

 Replying to myself, always a bad sign ;-)

 Use case: Darn, I missed the weekly project chat meeting, AGAIN...  
 Oooh,
 Bob is still online, let me see if I can download the meeting  
 activity
 entry.

 This might not be the best example, since by definition the chat
 meeting is an open collaboration, with a neighborhood (for example)
 sharing scope.

FWIW: I was assuming all chat participants has stopped the Activity  
(so not available in the neighbourhood), but that Bob (and his buddy  
icon) were still online.

 Misc supporting argument: If you default to Journal sharing OFF and  
 make it
 a new separate manual public sharing UI tick box/setting (required  
 for

 I'm not necessarily stating that it should be off by default
 (everything private). I'm simply arguing that it should be independent
 of the collaboration scope. What may make sense (maybe this is what
 you meant?) is to default all documents which become shared with the
 neighborhood to public, while all others would default to private.

Yes that's what I was trying to say :-) default all documents which  
become shared with the neighborhood to public :-) Though I'd missed  
your point that we would need some other UI in addition to this  
default, to allow someone to share an entry without collaboration.

Using the current Activity Share with: UI would indeed likely  
conflate collaboration with sharing, though it could still be worth  
investigating. Something along the lines of 3 modes Private,  
Collaborate with Neighbourhood, Public Journal entry (where  
Collaborate with Neighbourhood was collaborative and a public  
Journal entry).

 PS. I think we need to come up with some better terminology to
 distinguish between collaboration sharing and journal sharing. That
 would make this much easier to talk about.

You're not kidding there :-)

Regards,
--Gary

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

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

On 4 Jul 2009, at 03:18, Eben Eliason wrote:

 On Fri, Jul 3, 2009 at 9:52 PM, Andrés  
 Ambroisandresambr...@gmail.com wrote:
 On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote:
 On Fri, Jul 3, 2009 at 10:42 AM, Gary C  
 Marting...@garycmartin.com wrote:
 On 2 Jul 2009, at 14:47, Eben Eliason wrote:
 On Wed, Jul 1, 2009 at 1:42 PM, Aleksey  
 Limalsr...@member.fsf.org
 wrote:
 But in that case we should provide possibility to mark objects  
 that can
 be shared(I guess sharing all local objects by default is not a  
 nice
 idea).

 Right. This would be essential. There's definitely some thought  
 that
 needs to be done here.

 Scott had an interesting proposal which basically exposed the  
 Journal
 (or some subset of it) as an RSS feed. This was really neat,  
 because
 it meant we could build a UI for someone else's Journal in Sugar,
 populating it with that data, but also that these feeds could be
 shared globally, for anyone with an RSS reader to benefit from.  
 That's
 a really powerful approach in my mind, and there is some starter  
 code
 lying around as a proof of concept already!

 +1 to rss feed concept, makes life a lot easier in a heterogeneous
 environment.

 I'm still catching up on email so apologies if this has been  
 mentioned
 already. But the UI for marking of entries as sharable does not
 necessarily need to be another Journal user-interface addition**  
 In the
 simplest approach you could just extend the Activity Share with:  
 my
 Neighbourhood control to mark a Journal entry as part of the RRS  
 feed.
 Would need some

 The problem I see with this is that we're talking about two  
 different
 kinds of sharing. Just because I want to make a picture I drew
 available for anyone to look at, or even make a photocopy of to
 scribble on, doesn't mean that I want to let them into a shared
 painting session so they can scribble on the original with me.

 This is the difference between sharing an activity with someone
 collaboratively, and sending them (a copy of) the resulting object.

 thought on wording, do you add more levels of sharing? Or do you  
 just
 simplify the Share with: language language to Private, Share  
 with:
 Anyone.

 **though I would like entries to visually show their sharing  
 state, the
 buddy column hints at this but should be made explicit

 I do actually think that the Journal is the best place to expose  
 this,
 especially since the way we plan to expose the feature in the UI is
 something like view my friend's Journal. I'm not sure exactly  
 how
 or where that happens. Perhaps if we can abandon the checkbox for  
 the
 multi-selection we can use that space for a public/private toggle of
 some kind.

 How about using special tags? A Publish tag seems reasonable for  
 this, and
 consistent with the fact that it could live in a publish directory  
 an HTTP
 server would serve.

 I think it's a good idea to store these states as metadata, but I also
 think that we need to expose the feature visually to highlight the
 capability and make it easier to manage. I wouldn't want kids to have
 to type publish into the correct field in order to share their work.

 I can also imagine a tags used for starred entries and other  
 metadata (in a
 general sense) used by sugar. This would make them searchable as  
 well.

 Yup. I don't think this works yet, but the intent has always been to
 allow advanced search queries by specifying key:value pairs (as in
 gmail). In fact, all of the filters we support should have text
 equvalents, eg. cat kind:image with:alice favorite:yes (or similar).

This would solve one of my pet dislikes with the current solution.  
Once you've set up a Journal query, it's a pain to reset back to  
default. And the more filter options we provide the worse it would  
get. Ideally there would be a reset button – if selecting visual UI  
filter options added query text into the search field, the little (x)  
clear search field could be used to reset all options back to default  
in one click :-)

This would require the reverse to be true, so as you typed in the  
search field, any visual UI would need to update to match the query  
state. Cool, but quite a tough chunk of dev work.

Hmmm, actually that's not necessarily true. If you remove all visual  
UI feedback from the other toolbar controls, the search query string  
could be the feedback. Clicking, say the favourite star, would just  
inject favorite:yes into the query string, that would be your  
feedback... No other toolbar/button UI state would need to to be kept  
in sync (they all just inject query text).

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

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting