On Thu, Oct 23, 2008 at 4:31 AM, C. Scott Ananian [EMAIL PROTECTED] wrote:
On Tue, Oct 21, 2008 at 8:57 AM, [EMAIL PROTECTED] wrote:
can's mdns/avahi help with discovery? it'd be a shame to have to
manually configure a server address or name.
DNS-SD is the Right Answer (which is not exactly
Hi All,
We are planning a mini-conference at OLPC headquarters November 17 - 21.
For more information, see the conference wiki page at:
http://wiki.laptop.org/go/XOcamp_2
Please post any proposals for talks directly on the wiki page at:
http://wiki.laptop.org/go/XOcamp_2#Proposals
Starting at
I think that any activity that goes to the trouble of building their
own view source mechanism can handle the added overhead of adding a
line to the activity.info file. Seems like that is the easiest path.
Doesn't it have any negative repercussions in the long term?
-walter
On Thu, Oct 23, 2008
tomeu -- excellent! thanks for helping make progress on this.
tomeu wrote:
http://dev.laptop.org/~tomeu/viewsource.py
This approach has a good thing that is that works everywhere, but has
a major problem: doesn't let activities override it and handle
themselves the view source key
Am 23.10.2008 um 14:53 schrieb Tomeu Vizoso:
Hi,
I think that with a small effort, we could implement something much
better than what we have today.
We have glorious plans for the view source key, but as no resources
have been devoted to them, perhaps we should scale back and make sure
Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]:
an addition to activity.info, with sensible defaults, would be the
best bet, i think.
This would mean that sometimes the shell and sometimes the activity
would have to handle that key, which is fragile. I'd opt for the shell
always handling
bert wrote:
Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]:
an addition to activity.info, with sensible defaults, would be the
best bet, i think.
This would mean that sometimes the shell and sometimes the activity
would have to handle that key, which is fragile. I'd opt for
Am 23.10.2008 um 15:33 schrieb [EMAIL PROTECTED]:
bert wrote:
Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]:
an addition to activity.info, with sensible defaults, would be the
best bet, i think.
This would mean that sometimes the shell and sometimes the activity
would have to handle
On Thu, Oct 23, 2008 at 9:33 AM, [EMAIL PROTECTED] wrote:
sure, that's fine. but i think we need to keep thinking about
how to support of non-, or not-fully-sugarized applications with
every new feature we do (as well as with every revision of old
features).
I've got a half-baked idea about
http://www.gnome.org/~federico/news-2008-10.html#23
It's nice to not feel alone in this space anymore, isn't it??
Also finally a little of credit which doesn't hurt :)
Marco
___
Sugar mailing list
Sugar@lists.laptop.org
Mikus Grinbergs wrote:
I'm requesting discussion of two other improvements to control
facilities:
One more? Software Updates defaults all available Activities pre-selected.
Their boxes checked, in other words. I would rather choose the updates I
want than de-select the ones I don't. Some
I can sympathize with this perspective. Traditionally, software
updates only update software which is already installed. In this
perspective, I could see one expecting all those activities already
installed being selected by default, and others left unchecked for one
to select as desired.
On the
Of course you are right. I see now how my perspective as an isolated G1G1
user does not always jive with the primary XO users, A.K.A. the children of
the world! If specific deployments are using custom Activity Groups, then
my point is moot. My experience is with the various groups on the wiki,
13 matches
Mail list logo