[mozilla people, please feel free to skip to the bottom of this, for
the conclusion - the rest is detail]
right: i've just learned something very exciting: one of the pyjamas
contributors, a very intelligent individual, anthony, has been working
with the webkit-gtk team to create a gobject-introsp
hi todd, thanks for responding here.
On Tue, Feb 21, 2012 at 11:41 PM, Todd Whiteman wrote:
> PyXPCOM supports all XulRunner versions from 1.9.1 through to XulRunner 9.0
> - versions are tagged in hg here:
> http://hg.mozilla.org/pyxpcom/tags
... but debian has *already* moved on beyond xul
Note: Resent (as I needed to subscribe to sugar-devel).
On 12-02-21 02:32 PM, lkcl luke wrote:
pyxpcom is still actively maintained by toddw (activestate). I'm not clear
on what sugar/olpc actually desire here: the pyxpcom code works about as
well as it ever did.
there are only two versions
On Tue, Feb 21, 2012 at 7:59 PM, Brendan Eich wrote:
> I asked Benjamin Smedberg, who replied as follows:
thank you for notifying the right people, brendan.
related bugreports:
https://bugzilla.mozilla.org/show_bug.cgi?id=728645
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660482
> "
>
[summary to brendan and chris: chris, brendan, hi, i'm cc'ing you on
this because the OLPC team have been forced into making a decision to
move away from using xulrunner technology, as a direct result of the
decision made to reduce python-xpcom to third party status: it's taken
this long for the la
I have read you. You don't need repeat.
In first place, is really bad have this information now, and not 8 months
ago,
a lot of work was spent porting Browse to webkit,
and the result is no so bad like you say.
Of course, only few developers are using it, then do not have a real field
use.
The deci
On Tue, Feb 21, 2012 at 11:10 AM, Gonzalo Odiard wrote:
> You was replying a thread from Jun/2011. In this time the developers worked
> in a Browse
> version based in webkit.
yes. i'm aware of that. i strongly recommend reverting the changes made.
read what i wrote.
actually read what i wr
You was replying a thread from Jun/2011. In this time the developers worked
in a Browse
version based in webkit.
Gonzalo
On Tue, Feb 21, 2012 at 4:06 AM, lkcl luke wrote:
> http://trac.webkit.org/wiki/WebKit2
>
> ok: one of the issues that i ran into on the original (flawed)
> webkit-gobject de
http://trac.webkit.org/wiki/WebKit2
ok: one of the issues that i ran into on the original (flawed)
webkit-gobject development work, as well as the ports of pythonwebkit
to gtk and directfb, was quite how integrated the whole thing had to
be. there are now something like *eight* separate language
On Fri, Feb 17, 2012 at 5:07 PM, Jonas Smedegaard wrote:
> On 12-02-17 at 05:33am, Luke Kenneth Casson Leighton wrote:
>> better news: i've just confirmed that:
>>
>> a) the removal of js_push_context and pop context was a spurious
>> error, those functions are now restored, confirmed as compil
On 12-02-17 at 05:33am, Luke Kenneth Casson Leighton wrote:
> better news: i've just confirmed that:
>
> a) the removal of js_push_context and pop context was a spurious
>error, those functions are now restored, confirmed as compiling and
>existing (untested)
> b) the "usual" critical py
better news: i've just confirmed that:
a) the removal of js_push_context and pop context was a spurious error,
those functions are now restored, confirmed as compiling and existing
(untested)
b) the "usual" critical pyjamas-desktop tests, Helloworld, JSONRPCExample,
KitchenSink and Mail a
https://bugzilla.mozilla.org/show_bug.cgi?id=728055
success!
http://lkcl.net/hulahop/
ok, for a given definition of "success" :)
i had to comment out the js_push_context and js_pop_context
(could not be arsed to deal with those) - you might find that
you have to put in some #includes for spider
Marco Pesenti Gritti marcopg.org> writes:
>
> On 21 June 2011 23:23, Daniel Drake laptop.org> wrote:
> > You could have been even more convincing if you had used this API:
> > http://webkitgtk.org/reference/index.html
> > (yes, its webkit1, but it looks excellent from a GTK perspective, and
> >
Daniel Drake laptop.org> writes:
>
> There have been various discussions in the past suggesting a move from
> mozilla to webkit for the Browse activity and related components, but
> I've never really been convinced: there is always a cost to switching,
> and convincing-looking numbers from webki
On 24 Jun 2011, at 15:56, Lucian Branescu wrote:
> On 24 June 2011 15:13, Marco Pesenti Gritti wrote:
>> On 24 Jun 2011, at 13:08, Lucian Branescu wrote:
I would like to see a lot of experimentation with html activities
outside the platform before we even consider integrating. There i
On 24 June 2011 15:13, Marco Pesenti Gritti wrote:
> On 24 Jun 2011, at 13:08, Lucian Branescu wrote:
>>> I would like to see a lot of experimentation with html activities
>>> outside the platform before we even consider integrating. There is
>>> just too much unknown and possibilities, the ideas
On 24 Jun 2011, at 13:08, Lucian Branescu wrote:
>> I would like to see a lot of experimentation with html activities
>> outside the platform before we even consider integrating. There is
>> just too much unknown and possibilities, the ideas in this area needs
>> to be proven first.
>
> I don't r
On 24 June 2011 14:10, Daniel Drake wrote:
> On 24 June 2011 13:08, Lucian Branescu wrote:
>> Just nitpicking, but gtk2/pygi is a perfectly good option as well, and
>> it may even work with sugar-toolkit (depending on the status of
>> python-gobject and sugar-toolkit).
>
> According to a conversa
On 24 June 2011 13:08, Lucian Branescu wrote:
> Just nitpicking, but gtk2/pygi is a perfectly good option as well, and
> it may even work with sugar-toolkit (depending on the status of
> python-gobject and sugar-toolkit).
According to a conversation I had with Tomeu and J5 (pygi developers),
pygi
On 22 June 2011 12:54, Marco Pesenti Gritti wrote:
> On 21 June 2011 23:23, Daniel Drake wrote:
>> 2. In order to get Browse, Help and Wikipedia up and running on
>> webkit, do you see the need for a hulahop equivalent? Or some kind of
>> sugar-level web widget abstraction? Or just direct calls i
On 22 June 2011 19:02, Daniel Drake wrote:
> I think this is exciting and definitely a good area to explore, but at
> this point I'm trying to keep it separate from the "rescue Browse"
> operation. I outlined the reasoning here:
> http://wiki.sugarlabs.org/go/Features/WebKit
I totally agree with
Unless you are proposing that all of Sugar moves to C as a base; that
may have its merits but is a separate discussion, and not one I'm
going to get involved with. Feel free to start a new thread / Feature
page.
I am not proposing anything. I just showed an option that no one
considered. I m
2011/6/22 NoiseEHC :
> Why do not you implement the new Browse in C/C++?
Sugar is developed as a Python-based platform.
> It would have three advantages:
> 1. It could reuse an existing WebKit browser's code.
> 2. It would not depend on incomplete/unmaintained python bindings.
> 3. It would be fa
The biggest finding that came from outside this thread is that if
Browse is to move to pygi to access webkit, the Sugar python bits that
it uses must also be gtk3/pygi. No mixing with pygtk2 is possible. So
we have a prerequisite on sugar (or at least parts of it?) being moved
to gtk3/pygi first
On 22 June 2011 12:54, Marco Pesenti Gritti wrote:
> I'm not sure. I think hulahop in principle is pretty much equivalent
> to WebKitGtk + PyGi. In practice though I suspect there are going to
> be differences on the amount of code required to write something like
> Wikipedia and Help. If it's too
On 15 June 2011 05:58, Daniel Drake wrote:
> There have been various discussions in the past suggesting a move from
> mozilla to webkit for the Browse activity and related components, but
> I've never really been convinced: there is always a cost to switching,
> and convincing-looking numbers from
On 21 June 2011 23:23, Daniel Drake wrote:
> You could have been even more convincing if you had used this API:
> http://webkitgtk.org/reference/index.html
> (yes, its webkit1, but it looks excellent from a GTK perspective, and
> a breath of fresh air after seeing what mozilla put you through with
> 2. In order to get Browse, Help and Wikipedia up and running on
> webkit, do you see the need for a hulahop equivalent? Or some kind of
> sugar-level web widget abstraction? Or just direct calls into webkit.
>
>
>From the point of view of the activity, Wikipedia and Help are using the
same code o
On 14 June 2011 23:52, Marco Pesenti Gritti wrote:
> On 14 June 2011 20:58, Daniel Drake wrote:
>> 1. I've only made half the argument above. Mozilla is bad, but why is
>> WebKit the solution? The key questions here are: is it embeddable?
>> Does it work well when embedded? Do the developers supp
On 17 June 2011 18:13, Martin Langhoff wrote:
> On Fri, Jun 17, 2011 at 1:00 PM, Marco Pesenti Gritti
> wrote:
>> Did you test epiphany? I think that would give you a pretty decent
>> idea of what is achievable without putting work into WebKit itself.
>
> Not in a while. Earlier builds on Ubuntu
On Fri, Jun 17, 2011 at 1:00 PM, Marco Pesenti Gritti wrote:
> Did you test epiphany? I think that would give you a pretty decent
> idea of what is achievable without putting work into WebKit itself.
Not in a while. Earlier builds on Ubuntu were very unstable and buggy.
Just installed on F15 - w
On 17 June 2011 17:51, Martin Langhoff wrote:
> On Tue, Jun 14, 2011 at 6:52 PM, Marco Pesenti Gritti
> wrote:
>> With WebKit2, this all you need to load a web page into a GtkBox
>
> So that's my understanding of WebKit -- it's easily embeddable.
>
> I am not sure whether the API is as complete
On Tue, Jun 14, 2011 at 6:52 PM, Marco Pesenti Gritti wrote:
> With WebKit2, this all you need to load a web page into a GtkBox
So that's my understanding of WebKit -- it's easily embeddable.
I am not sure whether the API is as complete or as good as we want it.
IOWs, it's likely not a trivial j
On 14 June 2011 20:58, Daniel Drake wrote:
> 1. I've only made half the argument above. Mozilla is bad, but why is
> WebKit the solution? The key questions here are: is it embeddable?
> Does it work well when embedded? Do the developers support it being
> embedded?
With WebKit2, this all you need
On 14 June 2011 20:58, Daniel Drake wrote:
> 2. What is the state of Surf?
> This is the existing webkit-based browser for Sugar. Does it work
> well? Is it reliable? What are the gaping holes?
It works reasonably well. I couldn't implement cookies for example,
because that requires libsoup bindi
On Tue, Jun 14, 2011 at 4:42 PM, Daniel Drake wrote:
> On 14 June 2011 21:35, Peter Robinson wrote:
>> Would a skinned version of Firefox Mobile work for what is needed?
>
> No, as we need collaboration, journal access, etc. But (I didn't
> include this argument as I lost the link) this response
On 14 June 2011 21:35, Peter Robinson wrote:
> Would a skinned version of Firefox Mobile work for what is needed?
No, as we need collaboration, journal access, etc. But (I didn't
include this argument as I lost the link) this response matches what I
read from mozilla developers: if you want to bu
I'm not a developer so some of what I write is here say but from what I know
of from following various upstream.
On Tue, Jun 14, 2011 at 8:58 PM, Daniel Drake wrote:
> There have been various discussions in the past suggesting a move from
> mozilla to webkit for the Browse activity and related c
There have been various discussions in the past suggesting a move from
mozilla to webkit for the Browse activity and related components, but
I've never really been convinced: there is always a cost to switching,
and convincing-looking numbers from webkit supporters tended to be
countered with convi
40 matches
Mail list logo
