#2076 NORM Trial-3: Activity default name should include creator
Zarro Boogs per Child
bugtracker at laptop.org
Mon Sep 10 10:45:06 EDT 2007
#2076: Activity default name should include creator
--------------------------+-------------------------------------------------
Reporter: jfuhrer | Owner: dcbw
Type: enhancement | Status: new
Priority: normal | Milestone: Trial-3
Component: sugar | Version:
Resolution: | Keywords:
Verified: 0 |
--------------------------+-------------------------------------------------
Comment(by Eben):
Replying to [comment:2 smcv]:
> (1) is a job for the individual activities. Presence Service isn't
localized and doesn't know how to translate "Draw Activity" or indeed
"Walter's" (possessives are different in some languages, e.g. Afrikaans
would have "Walter se Tekenaktiwiteit"). Note that Connect does change its
name on startup, so this is feasible.
This is partially correct. We want activities to be able to provide a
default title, since they are best at knowing what is appropriate. On the
other hand, we also need a better defaults (eg. Sugar defaults) when the
activities don't do any extra work on their own. It's Sugar's job to
populate that field automatically, and it does know the activity name, the
username, and will of course be localized as well, which should allow it
to do so easily. We'd also like to add a default_title property to the
activity.info file allowing the activity to specify their own, which Sugar
would automatically use if present. This string should support env vars
so that they can insert the username, date, time, or other pieces of
relevant info.
> (2) would require Presence Service to track who started each activity as
an activity property. If we'd known this feature was required 2-3 weeks
ago, that would have been very useful. As it is, this will probably need
another round of Salut and PS changes.
This has been core to the mesh design since the very early days; My
apologies for not making this clearer via the wiki or otherwise. The
search feature is critical. I'll add some info about it to the
Specifications page on the wiki when I get a chance.
> (3) doesn't necessarily work like Eben thinks it does. Telepathy, and
the underlying XMPP and link-local-XMPP protocols we use, doesn't
guarantee any particular ordering when listing who's currently in a chat
room, so for any activity that started before we joined the server, the
participants will be in arbitrary order. While we *could* maintain a
parallel members list specifically for OLPC, the code, protocol and
network traffic required would probably be horrible.
I see. All of these designs sprung from user experience scenarios; At the
time I had no idea that there was an existing underlying protocol being
used. At any rate, we want the collaborative nature of the activities to,
for the most part, be owner agnostic (at the experience level). In light
of that statement, I actually don't feel strongly about indicating the
owner directly in the UI at all. On the other hand, if we do still have
an "owner", I'd prefer to keep the API free the particular term "owner"
and perhaps even "creator", instead using a term like "initiator" instead.
> Also, we don't currently support attaching a list of participants to an
invitation. Keeping this up to date would require quite wide-ranging
changes in both Gabble and Salut, so participant lists for invite-only
activities are not feasible for Trial-3 or FRS, I don't think.
This is a separate issue from the initiator, but this one I do have
stronger feelings about. I think that it's very important to know who is
participating in an activity before joining it. I do understand the
technical difficulties that arise with this requirement, though, and so
I'm happy to concede that it is really an enhancement for convenience, and
not essential at this stage.
--
Ticket URL: <https://dev.laptop.org/ticket/2076#comment:4>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system
More information about the Bugs
mailing list