Hi,
follow some comments on the suggested alternatives from Mike:
On Mon, 2007-10-22 at 16:36 -0400, Mike C. Fletcher wrote:
> Antoine van Gelder wrote:
> ...
> > The JokeMachine activity is a good example of an activity where 'resume'
> > by default makes sense.
> >
> > In this activity childre
You guys are caught up way to deep in technical detail already. I'd
place the desired user experience first, then see if this has
security implications, and then worry about implementation.
The *actual* problem right now is that resuming an activity is much
more complicated than simply click
Hi,
until we ship, we're instituting a new policy on blocker bugs:
* Any bugs being newly designated as FRS blockers need to have an e-
mail sent to the sugar@ or devel@ list (depending on which part of
the system they touch) with a short explanation of why this bug is a
blocker, any depende
On 10/23/07 08:53, Ivan Krstić wrote:
> When sending these e-mails, please copy and paste a line or two of
> the bug description itself into the e-mail along with a link to the
> full bug. For new blocker bugs, please use the subject 'new FRS
> blocker: #bugnumber', and for closed ones, 'clo
Bert Freudenberg wrote:
> You guys are caught up way to deep in technical detail already. I'd
> place the desired user experience first, then see if this has
> security implications, and then worry about implementation.
>
Bert, I realize that you've been doing a lot of the heavy lifting in
On Tue, 2007-10-23 at 09:27 -0400, Mike C. Fletcher wrote:
> Bert Freudenberg wrote:
> > You guys are caught up way to deep in technical detail already. I'd
> > place the desired user experience first, then see if this has
> > security implications, and then worry about implementation.
Agreed
Tomeu Vizoso wrote:
> Hi,
>
> follow some comments on the suggested alternatives from Mike:
>
> On Mon, 2007-10-22 at 16:36 -0400, Mike C. Fletcher wrote:
>
...
>> * Provide a mechanism in the Journal to flag a given entry/file as
>> "time-shared" with its future instances
>>
On Oct 23, 2007, at 2:58 PM, Bernardo Innocenti wrote:
> Wouldn't it be easier if we just CC'd devel@ in trac to achieve
> the same result?
That would work, if people were sure to include additional
information about bugs they're closing in Trac when they do so (is
fix in build? was something
On 10/23/07 10:04, Ivan Krstić wrote:
> That would work, if people were sure to include additional
> information about bugs they're closing in Trac when they do so (is
> fix in build? was something else touched to close this? anything else
> people should know?). Right now, most people aren'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tomeu Vizoso wrote:
> About making easier to resume existing entries, well... I have already
> said that we aim to improve this situation. Any other ideas in this
> direction are welcome.
The problem is that the Activity's developer thinks users shoul
Tomeu Vizoso wrote:
> On Tue, 2007-10-23 at 09:27 -0400, Mike C. Fletcher wrote:
>
>> Bert Freudenberg wrote:
>>
>>> You guys are caught up way to deep in technical detail already. I'd
>>> place the desired user experience first, then see if this has
>>> security implications, and then
Currently the XO is unable to use the slew of programs available, due to the
lack of a gui'ed package manager which necessitates command-line knowledge.
Also, the limited number of repos availible on the developmental builds
necessitates extensive googling to satisfy dependencies. I am working on a
Bert Freudenberg writes:
> We do *not* want to start with a clean state every time.
...
> I have personally observed this over the last months, with
> passers-by as well as with regular users like my own kids.
> Resuming from the Journal is a very rarely used feature.
> E.g., my son (8yo) really l
Without knowing more about how your wrapper works, I'm unable to offer
useful advice about how it will interact with activity containerization
(i.e. the relevant part of Bitfrost).
Can offer me a few words describing your design and implementation?
Thanks,
Michael
On Tue, Oct 23, 2007 at 12:42:
Hey,
while going through the activity grid
(http://wiki.laptop.org/go/Activities) I realized that there's no talk
of a sugarized e-mail client...
Can this indeed be true? Are the children only supposed to use webmail
solutions, maybe provided by the school or something?
I for one certainly th
On Oct 24, 2007, at 12:27 AM, Christoph Derndorfer wrote:
> Can this indeed be true? Are the children only supposed to use webmail
> solutions, maybe provided by the school or something?
For first ship, we're going with webmail because of infrastructure
challenges; we'd like to revisit this down
I've a gtk.Widget listening with "connect_after" to:
- "size-allocate"
- "show"
- "map"
- "realize"
But none of these is correctly telling me when the widget has actually
painted to the screen. Suggestions?
___
Sugar mailing list
Sugar@list
Hi,
please join un on #olpc-meeting tonight
Bug list: http://ln-s.net/15Oz
We've put an empty schedule here (please fill-in):
http://wiki.laptop.org/go/Status_meeting
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
Yesterday I had this idea: What about providing a secondary palette for the
activity launchers in the frame, that show some number of its most recent
activities, simillar to how the back button works in Browse? And a primary
option to show the journal filtered by that activity would still be there.
If my activity generates datastore entries other than the running activity's
datastore entry, what metadata on those entries can I set to associate them
with the activity that generated them?
Currently, I can associate metadata like 'preview' and 'icon-color' and
'mime_type' and 'title' with my en
On Oct 23, 2007, at 23:47 , Erik Blankinship wrote:
> If my activity generates datastore entries other than the running
> activity's datastore entry, what metadata on those entries can I
> set to associate them with the activity that generated them?
>
> Currently, I can associate metadata lik
Eduardo H Silva writes:
> Yesterday I had this idea: What about providing a secondary palette
> for the activity launchers in the frame, that show some number of
> its most recent activities, simillar to how the back button works
> in Browse? And a primary option to show the journal filtered by
>
22 matches
Mail list logo