On Thu, Oct 23, 2008 at 9:19 PM, C. Scott Ananian [EMAIL PROTECTED] wrote:
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
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
8 matches
Mail list logo