date:20090701

[Sugar-devel] Fwd: REVU: [ubuntu/karmic] gears 0.5.21.0~svn3334+dfsg-0ubuntu1 (New)

2009-07-01 Thread David Van Assche

interesting gears now .debbed for ubuntu guess alien might be
enough to make the rpm?

D

-- Forwarded message --
From: Stefan Lesicnik 
Date: Wed, Jul 1, 2009 at 2:19 PM
Subject: Re: REVU: [ubuntu/karmic] gears 0.5.21.0~svn3334+dfsg-0ubuntu1 (New)
To: Siegfried Gevatter 
Cc: Ubuntu-MOTU Mailing list 

On Wed, Jul 1, 2009 at 2:09 PM, Siegfried Gevatter wrote:
> -- Forwarded message --
> From: Ubuntu Installer 
> Date: 2009/7/1
> Subject: [ubuntu/karmic] gears 0.5.21.0~svn3334+dfsg-0ubuntu1 (New)
> To: Siegfried Gevatter , MOTU
> , Stefan Lesicnik 
>
>
> NEW: gears_0.5.21.0~svn3334+dfsg.orig.tar.gz
> NEW: gears_0.5.21.0~svn3334+dfsg-0ubuntu1.diff.gz
> NEW: gears_0.5.21.0~svn3334+dfsg-0ubuntu1.dsc
>
> gears (0.5.21.0~svn3334+dfsg-0ubuntu1) karmic; urgency=low
>
>  * Initial release (LP: #244245).

Hey! Just to let everyone know, this works for x86 & amd64!  Gears
from the .xpi from the website doesn't support 64! It also works with
Prism. I am pretty sure we are the first distribution to include gears
in our repo.

At the moment, Firefox 3.5 is not supported.  - As soon as upstream
releases code that starts to work, I will update this.

Stefan

--
Ubuntu-motu mailing list
ubuntu-m...@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
___
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-01 Thread Sascha Silbe

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 "term"s 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

CU Sascha

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

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

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

2009-07-01 Thread Gary C Martin

On 1 Jul 2009, at 10:54, Tomeu Vizoso wrote:
> On Mon, Jun 29, 2009 at 18:14, Gary C Martin  
> wrote:
>> - Showing tags under the title would be great (Tomeu, I will help  
>> where I
>> can)
>
> Hope to push my work on the journal treeview soon, then you can take
> it and do whatever graphics modifications you want.

Fab.

>> - Batch entry modification (FWIW, don't like the tick box, that  
>> feels like
>> an old school html web form hack)
>
> Any alternative?

I see multi selection Journal operations as a more advanced  
(occasional use) feature, so it would be OK not being directly  
visually exposed. So, no tick box column (save all that space for  
useful information), instead use a shift key modifier so that when  
clicking an entry its selection state is toggled on/off (grey backing  
fill of the entry row). When hovering over (or right clicking) a multi  
selected entry, display a new palette with just the features that  
function on a multiple selection. "Erase" being the obvious multiple  
selection command asked for in the past; the other useful multiple  
selection function would be drag and drop for copying a batch of  
Journal entries to and from external media (i.e. teacher comes back  
from the city with a USB stick full of downloaded ebooks).

>> - 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.

>> - Perhaps a Tag toolbar filter palette (could be a mini tag cloud)
>
> Could you draw a quick napkin mockup to illustrate that?

Sure, but don't think I'll have anything in time for the dev meeting.

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

Re: [Sugar-devel] Show Must Go On - SoaS for the XO-1

2009-07-01 Thread S Page

On Wed, Jun 17, 2009 at 2:12 AM, Martin Dengler wrote:
> I'd suggest you ask sdz to make the .iso that he used to create the
> .img file.

On Wed, Jun 17, 2009 at 12:37 AM, Sebastian Dziallas wrote:
> I'm very pleased to announce the first early preview of a new generation
> of SoaS XO-1 images.
Sir, could you upload the .iso for this image somewhere, maybe in a
subdirectory of http://download.sugarlabs.org/soas/xoimages/ ?

On Wed, Jun 17, 2009 at 3:24 AM, Martin
Langhoff wrote:
> Actually, a tool that's most of this smartly, it's called jigdo,

http://atterer.net/jigdo/ is indeed cool.  It's presented as a tool
for delivering and updating pieces of a single big file and all
examples are a .iso big file.  So long as it can also/instead use the
same pieces to create a different kind of big file such as a bootable
Live USB, or a writable SD partition, or XO-1 NAND contents, then it
is indeed a great solution.  Do the developers who work on Live USB
Creator know about jigdo?

Cheers,
--
=S Page
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Systems] Sunjammer down for unplanned maintenance

2009-07-01 Thread Bernie Innocenti

On Wed, 2009-07-01 at 19:49 +0200, Bernie Innocenti wrote:

> The FSF admins are working on fixing the problem.  The server should be
> back up and running within a few minutes.

Sunjammer has been bought back up a few hours ago.

Anyone who would like to receive notifications regarding our servers
hosted at the FSF, you can subscribe to this feed:

  http://identi.ca/group/fsfstatus

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/


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

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

2009-07-01 Thread Aleksey Lim

On Wed, Jul 01, 2009 at 05:42:14PM +, Aleksey Lim wrote:
> On Wed, Jul 01, 2009 at 09:48:23AM -0400, Eben Eliason wrote:
> > On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Lim wrote:
> > > On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote:
> > >> Hi,
> > >>
> > >> in this week we want to talk about the Journal and datastore [1]
> > >> improvements planned for 0.86. The Library activity [2] has shown some
> > >> interesting concepts as well. What are the common goals, how to move
> > >> forward, where to invest?
> > >
> > > Just some thoughts before meeting.
> > >
> > > For new Journal we have:
> > > * action-centric view
> > > * object-centric view
> > >
> > > In my mind they are quite different,
> > > action-centric view relates to timelines when object-centric is more
> > > like a browsing of objects(sort, tag them etc).
> > >
> > > So, what about using Library's code base for object-centric view?
> > 
> > I think Library and Scott's "Journal 2" are both good sources to pull
> > from. From a UI perspective, however, I think keeping to something
> > very much like the existing mockups is the best course, both because
> > this is a familiar ground for users (the initial vision for object
> > view is nearly identical to the current Journal UI) and because it's
> > important to keep it simple while finding intuitive ways to extend
> > functionality. I think exposing tags, adding tag autocompletion,  and
> > improving the selection filters in the toolbar are good places to
> > start.
> 
> I'm a bit concerned by having(many?) filter combo-boxes in toolbar[1],
> maybe having sidebar(like in Library[2]) could make more sense(btw user can
> hide sidebar to browse objects in "full window" mode), moreover we could
> use several views for entries in sidebar: list(tree) view, tag cloud[3].
> 
> > Adding the grid view to expose object previews would also be a
> > great addition!
> > 
> > I also like that Library has started to support sharing. I think there
> > have been a number of interesting proposals for how this might work in
> > the Journal, and I'd love to see the feature added. Perhaps by
> > selecting "View Journal" in the palette for a buddy it would be
> > possible to see anyone's shared content.
> 
> The original idea of Library in case of sharing was shared(common) collections
> of sugar objects i.e.:
> * user #1 creates collection(Library object), creation means choosing
>   filter for local objects(user tags, properties like mime-type, another
>   DS fields)
> * user #1 shares his collection(Library object)
> * user #2 can join #1's session and see(download) objects from his collection
> * user #2 can add his local objects to this shared collection(by setting
>   filter for his local objects)
>   so, all joined users can view all(from all users) shared objects in
>   one place
> 
> Having "View Journal" option in buddy menu makes sense as well
> 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).
> And Library's method doesn't fit well for this(since it uses filter and
> adding one particular object to collection(shared list) is a problem).
> 
> I thought about this issue in context of Library.. and what about:
> Extend conception of Favorites to Pins. The idea is:
> 
> - having implicit list of Library-collections/shared-collections means
>   problem to support these lists(if user deletes some object, sugar 
>   should update all these collection lists implicitly)
> - contrariwise, having in object implicit list of all collection links that
>   this object participates in, means also some odd implicit job to
>   support these links
> + so, what about delegation this job to users and make this process explicit
> + sugar does not do odd job of implicit supporting lists of links
> + users can understand what objects go to what collections(like
>   collection of objects to share, collection of starred objects, users
>   collections)
> * old Favorites mark would be a "pre-installed" pin
>   so, we could have several standard pins:
>   * pins for objects to share
>   * Favorites could be transformed to pins to show objects in home view
> so any object(not only activities) could appear in home view
>   * ...
> * each pin could have unique color(and name)
> * like Favorites pins could be attached to objects from list view(there
>   is no needs to open details dialog)
> * each objects can have several pins attached at the same time
> * we can render all these attached pins in one cell(not in per-pin cells
>   like for participants) i.e. pins will overlap each over
> 
> [1] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#3
> [2] http://wiki.sugarlabs.org/go/File:-1.png
> [3] http://wiki.sugarlabs.org/go/File:-2.png

sorry, forgot to mention - its all about object-centric view

-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.or

41 matches

Mail list logo