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
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
bert wrote:
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
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
