On 04/17/2013 05:39 PM, Daniel Narvaez wrote:
Thanks Daniel. Lots of interesting points here!
[...]
3. I see this project as a way of taking us closer to Sugar (in some
sense) on Android. Can Chrome webapps work as first-class citizens on
Android?
That's actually something I was thinking
On 04/22/2013 12:24 PM, Simon Schampijer wrote:
On 04/17/2013 05:39 PM, Daniel Narvaez wrote:
Thanks Daniel. Lots of interesting points here!
[...]
3. I see this project as a way of taking us closer to Sugar (in some
sense) on Android. Can Chrome webapps work as first-class citizens on
On 04/17/2013 07:20 PM, Daniel Drake wrote:
On Wed, Apr 17, 2013 at 9:39 AM, Daniel Narvaez dwnarv...@gmail.com wrote:
But is WebKit so much better? For example the WebKit2 decision _seems_ to
have been made by Apple engineers without even talking to major
contributors. The gtk bits are
On 18 Apr 2013 17:37, Daniel Narvaez dwnarv...@gmail.com wrote:
On 18 April 2013 10:25, Simon Schampijer si...@schampijer.de wrote:
I guess with Chrome we run into the same issues as with Android
regarding the openness, irregular code drops etc.
I think Chrome is better than Android in that
On 04/11/2013 09:52 PM, Daniel Narvaez wrote:
Hello,
I spent some time today thinking and experimenting with Chromium
integration and I have a more detailed plan to propose now.
There is an important premise to be made. In both Chromium and Firefox OS,
application's installation is very much
On 17 April 2013 12:31, Simon Schampijer si...@schampijer.de wrote:
Hey Daniel,
I have an extension that is using management.getAll [1] to collect the
extension info. I could not find any info about
chrome.runtime.connectNative, it is not part of [2], do you have any
pointers?
Hi Simon,
On 04/13/2013 02:42 AM, Daniel Narvaez wrote:
On 12 April 2013 23:18, Daniel Narvaez dwnarv...@gmail.com wrote:
Hi Lionel,
we are more or less understanding each other :) I think there are really
three possible steps
1 A WebView with an html5/javascript based sugar-toolkit
2 Support for web
On Fri, Apr 12, 2013 at 6:42 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
I might not have yet made explicit what a web application provides on the
top of an html page loaded in a browser, which is what we get with 1. Taking
a look to the Chromium documentation is a good way to get an idea of
Thanks Daniel. Lots of interesting points here!
On 17 April 2013 16:26, Daniel Drake d...@laptop.org wrote:
So the real benefit of the Chrome thing is the system integration? Is
that something really needed for Sugar? It would be necessary if we
were to port *all* Sugar activities to
On 17 April 2013 17:39, Daniel Narvaez dwnarv...@gmail.com wrote:
On 17 April 2013 16:26, Daniel Drake d...@laptop.org wrote:
So the real benefit of the Chrome thing is the system integration? Is
that something really needed for Sugar? It would be necessary if we
were to port *all* Sugar
On Wed, Apr 17, 2013 at 9:39 AM, Daniel Narvaez dwnarv...@gmail.com wrote:
But is WebKit so much better? For example the WebKit2 decision _seems_ to
have been made by Apple engineers without even talking to major
contributors. The gtk bits are maintained the way we would like them to
but...
On 17 April 2013 19:20, Daniel Drake d...@laptop.org wrote:
On Wed, Apr 17, 2013 at 9:39 AM, Daniel Narvaez dwnarv...@gmail.com
wrote:
But is WebKit so much better? For example the WebKit2 decision _seems_ to
have been made by Apple engineers without even talking to major
contributors.
Coming back to this point...
I think supporting an existing webapps framework (hopefully a standard at
some point) with it's system API, manifest, permissions etc, is important
also if the goal is just to get some Sugar activities running on other
platforms.
For example, even *if*
On 17 April 2013 19:40, Gonzalo Odiard gonz...@laptop.org wrote:
Coming back to this point...
I think supporting an existing webapps framework (hopefully a standard at
some point) with it's system API, manifest, permissions etc, is important
also if the goal is just to get some Sugar
I think it would be easier to evaluate if someone wrote down a proposal
for the js API :)
Yes, Im going to work of that.
In a meantime Ive drawn a global schema architecture:
http://wiki.sugarlabs.org/go/File:SugarWebApp_Architecture.svg
Its more the step 1 architecture but its easy
It would be good to do a bit of memory profiling with this approach. I'm
worried that running multiple webkit processes might use a lot memory
(thinking of memory cache for example).
Weve just qualified Sugar 0.96 for our Nosy Komba so Ive played with some
already existing WebKit
Hi William,
can you be more specific? Why do you think it's too taxing? Did you profile
it?
I'm not sure what you mean with instance, but it would be one Chromium
window per activity.
In theory I wouldn't expect a big difference. Chromium is built on the top
of WebKit.. It's replacing the
we are more or less understanding each other :)
Yes youre right, great to hear that finally we talked about the same thing
:-)
My feeling is that we should target step 2 directly, because 1 - 2 will
waste too much work. The datastore and collaboration implementation is going
to be pretty
On 13 April 2013 16:08, lio...@olpc-france.org wrote:
My feeling is that we should target step 2 directly, because 1 - 2
will waste too much work. The datastore and collaboration implementation
is going to be pretty different, depending if we use Chromium or Webkit
embedding.
Not so waste
On 12 April 2013 23:18, Daniel Narvaez dwnarv...@gmail.com wrote:
Hi Lionel,
we are more or less understanding each other :) I think there are really
three possible steps
1 A WebView with an html5/javascript based sugar-toolkit
It would be good to do a bit of memory profiling with this
I like the general idea.
Question:
This means a Chromium process should be working all time?
Gonzalo
On Thu, Apr 11, 2013 at 4:52 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
Hello,
I spent some time today thinking and experimenting with Chromium
integration and I have a more detailed
On 12 April 2013 12:48, Gonzalo Odiard gonz...@laptop.org wrote:
I like the general idea.
Question:
This means a Chromium process should be working all time?
That's the case in the implementation I described.
Though I think it could be optimized to avoid that. If the shell caches the
apps
Hi Daniel,
Impressive idea with a cool architecture. BTW, to be honest I think its
too complex.
Why not just create a standard Python activity template that call the WebKit
WebView? Like we do today.
But maybe I miss something or maybe we dont speak of the same thing?
When I wrote
Hi Lionel,
we are more or less understanding each other :) I think there are really
three possible steps
1 A WebView with an html5/javascript based sugar-toolkit
2 Support for web activities along with native ones, inside a native shell
3 Fully html5 sugar
My feeling is that we should target
On 12 April 2013 23:18, Daniel Narvaez dwnarv...@gmail.com wrote:
Hi Lionel,
we are more or less understanding each other :) I think there are really
three possible steps
1 A WebView with an html5/javascript based sugar-toolkit
2 Support for web activities along with native ones, inside a
I'm pretty new to the
mailing list and the project, but I'm pretty sure that starting a new
Chrome instance for every launched activity is far too taxing for the
XOs.
I think that Lionel's idea of using a Python activity that uses the
WebKit WebView is a much, much better solution.
Hello,
I spent some time today thinking and experimenting with Chromium
integration and I have a more detailed plan to propose now.
There is an important premise to be made. In both Chromium and Firefox OS,
application's installation is very much in the hands of the web browser. It
happens as
27 matches
Mail list logo
