[Sugar-devel] Stepping down

[Lucian Branescu]

This email is long overdue.

As you might have noticed, I haven't contributed to Browse/Sugar in a
long time. It was partly frustration with the technologies
(GTK3/introspection migration, I hate you), partly lack of money; but
mostly it was lack of spare time.

I still don't have any more free time to devote to Sugar development
now, so I wanted to let everyone that hasn't already noticed that I
can't be depended on to maintain Browse. Also, I won't be paying much
attention to the mailing list(s).

Sugar was my gateway to real software development and I'd like to
thank everyone that was patient with me and helped me along.

I still like Sugar, and I'm not going anywhere, so if anyone wants to
contact me about anything don't hesitate.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Please get surf-115.xo nominated and thus visible on ASLO

[Lucian Branescu]

Surf is simply not ready, and broken in many ways. I haven't had time
to work on it, or Browse for that matter.

Also, a fully working Surf requires moving to pygobject-introspection
(in the whole of sugar-toolkit), which might require moving to gtk3 as
well.

On 16 September 2011 04:28, Thomas C Gilliard
 wrote:
>
>
> Rafael Ortiz wrote:
>
> On Thu, Sep 15, 2011 at 7:30 AM, Thomas C Gilliard <
> satel...@bendbroadband.com> wrote:
>
>
>
> Please get surf-115.xo Nominated
>
> It is an inactive state on ASLO
>
> http://activities.sugarlabs.**org//en-US/sugar/
>
> and thus can only be listed in experimental listings (not visible to the
> public)
>
> We are using it as main browser in our f15 Soas (Sugar on a Stick) spin as
> Browse no longer works
> (xulrunner-1.9 is no longer supported )
>
> References : (archived surf-115.xo; git and .rpm)
> http://wiki.sugarlabs.org/go/**Sugar_Creation_Kit#surf_**browser
>
>
> The maintainer/developer hasn't uploaded latest versions to ASLO.
>
>
> Last one is v6
>
> http://activities.sugarlabs.org/en-US/sugar/downloads/file/25930/surf-106.xo
>
> I've just changed it this version to public.
>
>
> I get "file not found" on this link.  :  (
>
> Searches on Surf and surf come up empty
>
> Tom Gilliard
> satellit
>
> Cheers.
>
>
>
>
> Thanks for your help.
>
> Tom Gilliard
> sugarlabs volunteer
> __**_
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.**org 
> http://lists.sugarlabs.org/**listinfo/sugar-devel
>
>
>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Statically Built Chromium for my XO

[Lucian Branescu]

It's likely that those libraries already exist on your machine, but
with slightly different names. You could install them, too.

Try making symlinks in the chromium dir to the real libs.

On 10 August 2011 10:23, Basanta Shrestha  wrote:
> Hi,
> I am looking to install chromium on my XO. Recently I downloaded a
> build from http://build.chromium.org/f/chromium/snapshots/ and tried
> to run it under the XO. Without much surprise, it complained about lot
> of missing libraries. What I am looking for now is a chromium which
> has been build statically. Can anyone point me a link to such a file
> or a process to do so.
>
> Specifications:
> XO-1
> Sugar: 0.82.1
> OLPC release 9 ( Joyride)
>
> --
> Basanta Shrestha
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse and the move to WebKit

[Lucian Branescu]

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 in this area needs
>>> to be proven first.
>>
>> I don't really see what integration with Sugar needs to be achieved
>> that isn't possible using the same APIs as any other activity. A
>> html/js/node equivalent of sugar-toolkit would be useful, but I don't
>> see any integration necessary beyond that.
>
> I didn't mean integration of the HTML activities stuff with Sugar but 
> integration (inclusion) of the HTML activities stuff in the Sugar platform.

Right. But that first requires a sugar-web-toolkit to exist :) The way
I see it, after one such toolkit has been written, it can be decided
whether or not to bundle it with Sugar.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse and the move to WebKit

[Lucian Branescu]

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 conversation I had with Tomeu and J5 (pygi developers),
> pygi introspection to gtk2 libraries does not work well and is
> unsupported. Also, mixing pygi with pygtk is impossible and will fall
> over immediately. According to them, pure gtk3 is the only solution.

Hmm, that's quite different from my last talk with them. I was told
that gtk2 is fine and that since py-gi is based on pygobject, there's
a chance it might work with pygtk2.

Not having gtk2 support is quite nasty, and it changes a lot of plans.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse and the move to WebKit

[Lucian Branescu]

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 into webkit.
>
> 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 much, people will just cut/paste the
> whole Browse, which I think we should avoid.
>
> The way I would approach it, is to first port Browse basing it
> directly on WebKitGtk. Then port Help or Wikipedia and see if it make
> sense to share code. If it's generic enough to be upstreamed we should
> try to. If it's sugar specific, adding it to sugar-toolkit would
> probably make sense (a common toolbar implementation for example?).

In my porting of Browse from hulahop to pywebkitgtk, the code got a
lot smaller. WebKit's API is in fact much nicer and much more complete
than what hulahop offers, the latter requiring direct XPCOM usage. No
need for a hulahop-webkit.



On 22 June 2011 19:02, Daniel Drake  wrote:
> 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.

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). In the worst case, gtk2/pygi would
have to be used with a port of sugar-toolkit to pygi. There is no need
to bother with gtk3.

Also, it'll be much easier to move Surf from pygtk2/pywebkitgtk to
gtk2/pygi than to gtk3/pygi anyway.



On 23 June 2011 13:16, Marco Pesenti Gritti  wrote:
> 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 you there.
>
> 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 really see what integration with Sugar needs to be achieved
that isn't possible using the same APIs as any other activity. A
html/js/node equivalent of sugar-toolkit would be useful, but I don't
see any integration necessary beyond that.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse and the move to WebKit

[Lucian Branescu]

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 bindings. libsoup folks recommended I
use pygi. There are a few other gaps in functionality.

Surf is forked from Browse a few versions back (I think 119). Some new
features could be backported from newer Browse, but overall I consider
the Surf codebase in a reasonable state, just incomplete.

> 3. What is the safe of pywebkitgtk in F14, F15, F16?
> This is the backend library used by Surf, right? Is this still the
> right answer for creating a webkit-based app using Python + GTK?
> Does it work well on Fedora 14, or do we need a newer distro?
>
> I remember at one point there being some pretty key problems with
> pywebkitgtk causing Surf development to halt. What were these issues
> and have they been overcome?

pywebkitgtk is unmaintained, and its author has moved to pygi.
Switching to pygi shouldn't be hard at all from what I've seen, it's
an almost entirely automated process.

> IIRC those pywebkitgtk-related problems were going to be solved with a
> move to GObject introspection, which wasn't mature back in that
> timeframe. But it is mature and usable now. But does this require us
> to move to GTK+-3?

pygi itself is much more mature, indeed. However, last year there were
significant problems with using sugar-toolkit together with pygi,
since sugar-toolkit uses (used?) static bindings. I don't know what
the status is now, the issues may no longer exist. iirc, part of the
reason pygi was merged in pygobject was to better support static
bindings based on pygobject.

It doesn't require moving to GTK3, which is entirely orthogonal to pygi afaik.

> Does WebKit/webkitgtk work for both GTK+-2 and GTK+-3? Any pros/cons
> of one over the other?

I don't know about the state of their GTK3 port, but I believe they're
working on it.



On 14 June 2011 22:05, C. Scott Ananian  wrote:
> 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 matches what I
>> read from mozilla developers: if you want to build a mozilla-based
>> product, fork the mozilla codebase and write your application inside
>> there.
>
> I did work on that; you can certainly make a firefox extension that
> supports collaboration, journal access, etc.  My firefox activity did
> some of what's necessary.  Firefox can speak dbus, etc.

Yes, if mozilla is desired, the way to go is to extend xulrunner, not
embed it. An alternative chrome and a couple of extensions for sugar
integration would provide that.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH Browse 1/2] Fix Stopping if downloads are in progress

[Lucian Branescu]

On 23 May 2011 17:46, Rafael Ortiz  wrote:
>
>
> On Mon, May 23, 2011 at 11:28 AM, Lucian Branescu
>  wrote:
>>
>> I gave you commit and review rights. Feel free to commit the two
>> patches yourself, removing me as a bottleneck.
>>
>
> Ok Thanks Lucian, about new releases, are you available to do so ? or should
> I ?  ;).

You can go ahead and release. I have exams this week, so very little spare time.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH Browse 1/2] Fix Stopping if downloads are in progress

[Lucian Branescu]

I gave you commit and review rights. Feel free to commit the two
patches yourself, removing me as a bottleneck.

On 23 May 2011 17:14, Lucian Branescu  wrote:
> Looks good, although it'd be nice at some point for Sugar itself to
> manage force closes better.
>
> Wouldn't it be better if I gave you commit rights on mainline instead?
>
> On 23 May 2011 16:30, Rafael Ortiz  wrote:
>>
>>
>> On Sat, May 21, 2011 at 10:24 AM, Sascha Silbe 
>> wrote:
>>>
>>> sugar.activity.activity.Activity.close() doesn't take a force parameter.
>>> Instead we need to make sure can_close() returns True the next time and
>>> call
>>> close() without parameters.
>>>
>>> The user-visible effect was that they needed to use Stop twice (once to
>>> stop
>>> the pending downloads and a second time to close Browse).
>>>
>>> Signed-off-by: Sascha Silbe 
>>> ---
>>>  webactivity.py |    9 +++--
>>>  1 files changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/webactivity.py b/webactivity.py
>>> index b444861..5f1ea5e 100644
>>> --- a/webactivity.py
>>> +++ b/webactivity.py
>>> @@ -184,6 +184,7 @@ class WebActivity(activity.Activity):
>>>
>>>         _logger.debug('Starting the web activity')
>>>
>>> +        self._force_close = False
>>>         self._tabbed_view = TabbedView()
>>>
>>>         _set_accept_languages()
>>> @@ -601,7 +602,9 @@ class WebActivity(activity.Activity):
>>>         return buf
>>>
>>>     def can_close(self):
>>> -        if downloadmanager.can_quit():
>>> +        if self._force_close:
>>> +            return True
>>> +        elif downloadmanager.can_quit():
>>>             return True
>>>         else:
>>>             alert = Alert()
>>> @@ -616,6 +619,7 @@ class WebActivity(activity.Activity):
>>>             alert.connect('response', self.__inprogress_response_cb)
>>>             alert.show()
>>>             self.present()
>>> +            return False
>>>
>>>     def __inprogress_response_cb(self, alert, response_id):
>>>         self.remove_alert(alert)
>>> @@ -623,8 +627,9 @@ class WebActivity(activity.Activity):
>>>             logging.debug('Keep on')
>>>         elif response_id == gtk.RESPONSE_OK:
>>>             logging.debug('Stop downloads and quit')
>>> +            self._force_close = True
>>>             downloadmanager.remove_all_downloads()
>>> -            self.close(force=True)
>>> +            self.close()
>>>
>>>     def get_document_path(self, async_cb, async_err_cb):
>>>         browser = self._tabbed_view.props.current_browser
>>> --
>>> 1.7.4.1
>>
>> Applied and tested, works as expected thanks.
>> Can you apply to mainline ?.
>>>
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH Browse 1/2] Fix Stopping if downloads are in progress

[Lucian Branescu]

Looks good, although it'd be nice at some point for Sugar itself to
manage force closes better.

Wouldn't it be better if I gave you commit rights on mainline instead?

On 23 May 2011 16:30, Rafael Ortiz  wrote:
>
>
> On Sat, May 21, 2011 at 10:24 AM, Sascha Silbe 
> wrote:
>>
>> sugar.activity.activity.Activity.close() doesn't take a force parameter.
>> Instead we need to make sure can_close() returns True the next time and
>> call
>> close() without parameters.
>>
>> The user-visible effect was that they needed to use Stop twice (once to
>> stop
>> the pending downloads and a second time to close Browse).
>>
>> Signed-off-by: Sascha Silbe 
>> ---
>>  webactivity.py |    9 +++--
>>  1 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/webactivity.py b/webactivity.py
>> index b444861..5f1ea5e 100644
>> --- a/webactivity.py
>> +++ b/webactivity.py
>> @@ -184,6 +184,7 @@ class WebActivity(activity.Activity):
>>
>>         _logger.debug('Starting the web activity')
>>
>> +        self._force_close = False
>>         self._tabbed_view = TabbedView()
>>
>>         _set_accept_languages()
>> @@ -601,7 +602,9 @@ class WebActivity(activity.Activity):
>>         return buf
>>
>>     def can_close(self):
>> -        if downloadmanager.can_quit():
>> +        if self._force_close:
>> +            return True
>> +        elif downloadmanager.can_quit():
>>             return True
>>         else:
>>             alert = Alert()
>> @@ -616,6 +619,7 @@ class WebActivity(activity.Activity):
>>             alert.connect('response', self.__inprogress_response_cb)
>>             alert.show()
>>             self.present()
>> +            return False
>>
>>     def __inprogress_response_cb(self, alert, response_id):
>>         self.remove_alert(alert)
>> @@ -623,8 +627,9 @@ class WebActivity(activity.Activity):
>>             logging.debug('Keep on')
>>         elif response_id == gtk.RESPONSE_OK:
>>             logging.debug('Stop downloads and quit')
>> +            self._force_close = True
>>             downloadmanager.remove_all_downloads()
>> -            self.close(force=True)
>> +            self.close()
>>
>>     def get_document_path(self, async_cb, async_err_cb):
>>         browser = self._tabbed_view.props.current_browser
>> --
>> 1.7.4.1
>
> Applied and tested, works as expected thanks.
> Can you apply to mainline ?.
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse activity

[Lucian Branescu]

On 18 May 2011 16:00, Gonzalo Odiard  wrote:
> On Wed, May 18, 2011 at 11:58 AM, Peter Robinson 
> wrote:
>> On Wed, May 18, 2011 at 3:49 PM, Art Hunkins  wrote:
>> > Yes, this is particularly crucial as there is no Browse in 0.92 Sugar.
>> > (I
>> > gather it is currently inoperable.) Thus there is no easy way of
>> > downloading
>> > Activities from the web. (I download them on another computer, copy to a
>> > USB
>> > drive, then drag to the Journal on the first computer.)
>>
>> Yes, it needs to be ported to the changes for xulrunner2 (firefox 4)
>> but we now ship Surf instead for the interim at least.
>>
>
> Yes? It's decided? Surf can replace Browse or we are replacing a mountain of
> bugs by another different mountain?

Right now Surf is incomplete. I haven't had any time to work on either
fixing Browse bugs or finishing Surf.

I do think the future is with webkit, not xulrunner2. Especially since
Mozilla care little about embedding.

> Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] XO1 | Same hardware, slower internet

[Lucian Branescu]

On 28 March 2011 23:01, Anish Mangal  wrote:
> Hi,
>
> With time, as hardware gets more complex, software gets bloated up to
> use the excess processor cycles available. A part of it is the
> websites that get more content heavy, bulky and slow with time.
> Considering that the hardware on the XO-1 is not going to get any
> faster, and websites _are_ going to get bulkier, I see a problem
> gradually arising.
>
> For example, Google image search, blogger and other similar services
> have recently refreshed their websites to be more user friendly at the
> cost of being heavier. I have seen kids trying to use these heavier
> websites in the classroom and it results in more time being wasted
> because of a overall slower computer.
>
> I would like to get opinions on what will be an increasingly
> significant issue, as websites get more complex and the hardware
> essentially remains the same.
>
> --
> Anish

Webkit should help somewhat. Once the XO 1 gets a reasonably recent
OS, Surf can be finished (in fact the porting could happen earlier,
but I don't have time for it until late summer).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Twisted Sugar Advice

[Lucian Branescu]

On 17 March 2011 16:45, Mike Rehner  wrote:
> I'm a retired computer science teacher with a limited amount of python
> experience. About a month and a half ago I decided to volunteer about 8-12
> hours a week of time to Sugar Labs. Unfortunately Sugar Labs is using a
> software stack that I am not very familiar with. I managed to learn git
> enough to get a project up and down. Being familiar with Ubuntu I set up an
> Ubuntu 10.4 LTS virtual machine running a Sugar emulator and an
> Eclipse/Pydev development environment. I got the FLOSS manual on Sugar
> Activities and learned that I needed to use the GTK framework. I wrote one
> or 2 simple gtk programs but did not port them over to Sugar.. Also at this
> time I agreed to work with someone from Columbus Girls School. Unfortunately
> her mother became ill and she had to leave for California. So I decided to
> learn "Python + GTK" developing a practice program.
>
> The program was a simple server that would ask drill math questions.
> Clients, either on the same machine or on a nearby machine would answer the
> math questions. This was not to be fully developed with error checking and
> all defs fully implemented but simply a proof of concept work to keep me on
> track in improving my Python skills. Twisted looked like a good match with
> GTK. So I wrote 1 or 2 simple Twisted client/server programs. Unfortunately
> learning and making 2 event driven frameworks Twisted + GTK play together
> nicely became very frustrating. It reminds me of the time I had to make
> Ubuntu and Windows play together nicely- I did it but it took me time and
> effort. So I have a following set of questions.

Are you using the gtk reactor?
http://twistedmatrix.com/documents/10.2.0/core/howto/choosing-reactor.html#auto11
It should "just work".

> Will Twisted play nicely with Sugar (i.e. should I keep going on with this
> model- writing a twisted (GTK?) question server with a Twisted + GTK answer
> client. My thinking on this model  is from my years of teaching is that
> students like to compete with each other and this model may add some
> collaborative learning when tweaked. Is this something worth continuing? I
> believe I can make Twisted + GTK work with difficulty  but I'm not sure that
> about Twisted in Sugar. There are two many unknowns for me.
> If anyone thinks Twisted + Sugar(GTK)  is worth pursuing, does anyone know
> of any good tutorials or information on this.
> If this is not worth pursuing what would be a good way I could devote about
> 8-12 hours to Sugar Labs Activities

It shouldn't work any differently in Sugar than with Gtk.

> cheers,
>
> Mike
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Problem downloading files using Browse Activity

[Lucian Branescu]

I've reopened the ticket, feel free to post this log there.

I'll have a look.
On Wednesday, 23 February 2011 at 14:01, Daniel Castelo wrote: 
> We have some problems using browse activity V120. We can't download files 
> attached in gmail (apparently happen with many sites)
> 
> The activity doesn't show any error message. If I read the log I get::
> 
> ERROR:xpcom:Unhandled exception calling 'int8 createChromeWindow(in 
> nsISomething, in uint32, out retval nsISomething);'
>  Traceback (most recent call last):
>  File "/usr/lib/xulrunner-1.9.1/python/xpcom/server/policy.py", line 277, in 
> _CallMethod_
>  return 0, func(*params)
>  File "/home/olpc/Activities/Browse.activity/browser.py", line 149, in 
> createChromeWindow
>  parent_dom_window = parent.webBrowser.contentDOMWindow
> AttributeError: 'NoneType' object has no attribute 'webBrowser'
> 1298464623.020300 ERROR xpcom: Unhandled exception calling 'int8 
> createChromeWindow(in nsISomething, in uint32, out retval nsISomething);'
>  Traceback (most recent call last):
>  File "/usr/lib/xulrunner-1.9.1/python/xpcom/server/policy.py", line 277, in 
> _CallMethod_
>  return 0, func(*params)
>  File "/home/olpc/Activities/Browse.activity/browser.py", line 149, in 
> createChromeWindow
>  parent_dom_window = parent.webBrowser.contentDOMWindow
> AttributeError: 'NoneType' object has no attribute 'webBrowser'
> ERROR:xpcom:Unhandled exception calling 'int8 createChromeWindow(in 
> nsISomething, in uint32, out retval nsISomething);'
>  Traceback (most recent call last):
>  File "/usr/lib/xulrunner-1.9.1/python/xpcom/server/policy.py", line 277, in 
> _CallMethod_
>  return 0, func(*params)
>  File "/home/olpc/Activities/Browse.activity/browser.py", line 149, in 
> createChromeWindow
>  parent_dom_window = parent.webBrowser.contentDOMWindow
> AttributeError: 'NoneType' object has no attribute 'webBrowser'
> 1298464625.116524 ERROR xpcom: Unhandled exception calling 'int8 
> createChromeWindow(in nsISomething, in uint32, out retval nsISomething);'
>  Traceback (most recent call last):
>  File "/usr/lib/xulrunner-1.9.1/python/xpcom/server/policy.py", line 277, in 
> _CallMethod_
>  return 0, func(*params)
>  File "/home/olpc/Activities/Browse.activity/browser.py", line 149, in 
> createChromeWindow
>  parent_dom_window = parent.webBrowser.contentDOMWindow
> AttributeError: 'NoneType' object has no attribute 'webBrowser'
> 
> I found this ticket http://bugs.sugarlabs.org/ticket/776
> 
> Have you got any idea?
> 
> Regards, Daniel
> 
> 
> -- 
> Ing. Daniel Castelo
> Plan Ceibal - Área Técnica
> Avda. Italia 6201
> Montevideo - Uruguay.
> Tel.: 2 601 57 73 Interno 2228
> E-mail : dcast...@plan.ceibal.edu.uy
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH Read] adapt to evince 2.30 API (SL#1900)

[Lucian Branescu]

Thanks a lot for finding the time to do this, I've been much more busy
than anyone should be lately. It even took me 10 days to reply to this
:)

On 5 December 2010 12:41, Sascha Silbe  wrote:
> From: Lucian Branescu Mihaila 
>
> PDFs are working fine, EPub support is limited:
>  - search not working
>  - copy to clipboard disabled
>  - zoom disabled
>  - page next/prev disabled
>
> Tested-by: Sascha Silbe 
> [combined into a single patch, wrote patch description, minor style clean-ups]
> Signed-off-by: Sascha Silbe 
> ---
>  Based on my clean-up patches, so those need to be merged first.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] GTK3 rendered in a browser

[Lucian Branescu]

On 24 November 2010 17:52, Sameer Verma  wrote:
> Saw this and instantly thought of Sugar being rendered in a browser.
> http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/

Looks interesting. Solutions like this would help to deprecate X11.

Although for Sugar in a browser, you'd need a server with enough
resources for each connected user.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Eliminate Glucose co-maintainers

[Lucian Branescu]

On 22 November 2010 12:02, Simon Schampijer  wrote:
>
> On 11/22/2010 03:04 AM, Martin Dengler wrote:
>>
>> I propose we eliminate "co-maintainers" from Glucose[1] because they
>> reduce the responsibility and pressure of a sole maintainer.
>
> I see it the other way around. Reducing the pressure on a maintainer is a 
> good thing. If we only have one person doing the work we have a bottle neck. 
> This person gets tired more quickly. Furthermore we are a volunteer based 
> open source project. If people step down due to any reasons it is good to 
> have peers that can take over and that have been involved in the process 
> before.

I agree. Sascha and co-maintain Browse and while it's not ideal
(because we both have very little free time) it's still much better
than not having any maintenance at all. I don't tend to rely on Sascha
doing things because I know he's busy, so if I have time, I just do
things. From what I know, he does the same. There's no overlap because
everything is open (all patches get ml threads) and it's less likely
that at any point in time there's no one available to do some
important work.

> As example see the localization situation. Sayamindu stepped down (he was the 
> single coordinator) and we did not know what to do for localization then.
>
> About responsibility, of course I can only report about my experience from 
> being a co-maintainer: I don't think I have been caring less about the shell 
> release just because I have been the co maintainer.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Audio tag not wroking in browse

[Lucian Branescu]

It's up to xulrunner (gecko) to support . What version of 
xulrunner are you using?On Sunday, 21 November 2010 at 09:36, javed khan 
wrote:i checked the html5 audio tag but it is not working, any patch for it___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RELEASE] Browse-120

[Lucian Branescu]

On 11 November 2010 16:40, Simon Schampijer  wrote:
> On 10/25/2010 10:36 AM, Lucian Branescu wrote:
>>
>> On 25 October 2010 09:25, Simon Schampijer  wrote:
>>>
>>> On 10/25/2010 09:31 AM, Jonas Smedegaard wrote:
>>>>
>>>> On Sun, Oct 24, 2010 at 06:51:15PM -0400, Lucian Branescu Mihaila wrote:
>>>>>
>>>>>
>>>>>
>>>>> http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-120.tar.bz2
>>>>>
>>>>
>>>> Please push a tag for that release.
>>>
>>> Hmm, somehow the history seems strange too. Lucian, can you verify that?
>>> Please, don't forget to do the release on the 0.90 branch.
>>>
>>> Btw, you can use the release script at [1]. Helps you not to forget the
>>> tagging etc, sends the email...
>>>
>>> Regards,
>>>   Simon
>>>
>>> [1]
>>>
>>> http://git.sugarlabs.org/projects/sugar-tools/repos/mainline/blobs/master/release
>>
>> I used the release script on the 0.90 branch. The history does look weird.
>>
>
> Something is weird here. Can you check if you pushed?
>
> http://git.sugarlabs.org/browse/mainline/commits/sucrose-0.90
>
> I do not get your changes when pulling and the history in gitorious does not
> show them neither.
>
> Btw, would be nice to upload the .xo on ASLO as well.
>
> Thanks,
>   Simon
>

I think the release script managed to screw things up. I'm not sure
what's going on, my git skills are low.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Appearance Customization

[Lucian Branescu]

It's not just that. Your android phone has a lot of ram and a much faster
cpu than the xo 1.0. And its java runtime is engineered especially for low
memory usage.

The xo 1.5 is much better. And python and sugar will get better.

On 7 Nov 2010 21:08, "Tabitha Roder"  wrote:

>  Re memory usage - we already go through the "please don't open too many
activities" routine all t...

How come my Android phone is okay with running everything at once? What does
it do that means I don't run out of memory? Can we do that to Sugar?
Apparently the phone is killing apps when it needs to but when you restart
the application it picks up where it left off (I might be repeating
something already discussed on this list?).
Back in the old days, Sugar showed you how many activities were running in
the home view, that might have been more obvious to kids that they were
overloading their laptops.
Would it be possible to have a message pop up that says "you are running out
of memory, which activity would you like to close" or similar so they are
alerted to running too much stuff.
Thanks
Tabitha

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RELEASE] Browse-120

[Lucian Branescu]

On 25 October 2010 09:25, Simon Schampijer  wrote:
> On 10/25/2010 09:31 AM, Jonas Smedegaard wrote:
>>
>> On Sun, Oct 24, 2010 at 06:51:15PM -0400, Lucian Branescu Mihaila wrote:
>>>
>>>
>>> http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-120.tar.bz2
>>>
>>
>> Please push a tag for that release.
>
> Hmm, somehow the history seems strange too. Lucian, can you verify that?
> Please, don't forget to do the release on the 0.90 branch.
>
> Btw, you can use the release script at [1]. Helps you not to forget the
> tagging etc, sends the email...
>
> Regards,
>   Simon
>
> [1]
> http://git.sugarlabs.org/projects/sugar-tools/repos/mainline/blobs/master/release

I used the release script on the 0.90 branch. The history does look weird.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] Browse-120

[Lucian Branescu Mihaila]

== Source ==

http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-120.tar.bz2

== News ==

* Release 120 (Lucian Branescu Mihaila)
* fix error writing file if there are not a url in the location bar (Gonzalo 
Odiard)
* Fix OLPC #6874 - Web activity uses gettext on file name (Gonzalo Odiard)
* Move to hashlib to avoid deprecation warnings. (Lucian Branescu Mihaila)
* Browse-side fix for #1638. For better names, more work is needed. (Lucian 
Branescu Mihaila)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] stepping down as maintainer

[Lucian Branescu]

On 19 October 2010 17:50, Tomeu Vizoso  wrote:
> Hi,
>
> for personal reasons have to drastically reduce my involvement in the project.
>
> Will be leaving maintenance of my modules and unsubscribing from the
> mailing lists. My place on the board is vacant from now on and I'll be
> adding to the wiki the new vacancies:
> http://wiki.sugarlabs.org/go/Vacancies
>
> Cheers and good luck,
>
> Tomeu

Thank you for all the help and handholding :)

I wish you all the best.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Home button in browse - toolbar images

[Lucian Branescu]

On 22 October 2010 12:44, Gonzalo Odiard  wrote:
>
>
> On Fri, Oct 22, 2010 at 8:32 AM, Lucian Branescu 
> wrote:
>>
>> On 22 October 2010 12:05, Gonzalo Odiard  wrote:
>> > Lucien:
>> > I have added the patches to http://dev.laptop.org/ticket/10364
>> > Can you review it?
>>
>> Patch looks good, but it makes the toolbar extremely crowded. I'll
>> accept it for now, with the caveat of having a Browse toolbar overhaul
>> as soon as I get time for the other pressing issues (browse tab crash
>> and read brokenness).
>>
>
> Ok, if you want I can push it in 0.84 branch.

You should make a 0.90 branch first and then push your patch to the
master branch. We want to keep the 0.90 branch stable and only put in
manageable and low-risk fixes.

If you don't know how to make a branch, you'll have to wait 8-9h until
I get home.

> I agree with you, we must work in the toolbar.
>
> Gonzalo
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Home button in browse - toolbar images

[Lucian Branescu]

On 22 October 2010 12:05, Gonzalo Odiard  wrote:
> Lucien:
> I have added the patches to http://dev.laptop.org/ticket/10364
> Can you review it?

Patch looks good, but it makes the toolbar extremely crowded. I'll
accept it for now, with the caveat of having a Browse toolbar overhaul
as soon as I get time for the other pressing issues (browse tab crash
and read brokenness).

> If you will create a branch 0.90, probably must be done before pushing this
> tickets.

Yes, the home button thing should certainly be in a new branch. I'll
make the 0.90 branch when I get home (no git env here). Or if you have
access, you can create a branch yourself in the mainline repository.

> Please give me feedback about your plans.
> Thanks!
>
> Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Home button in browse - toolbar images

[Lucian Branescu]

On 20 October 2010 19:13, Gary Martin  wrote:
> On 19 Oct 2010, at 22:42, Lucian Branescu wrote:
>
>> 2010/10/19 NoiseEHC :
>>> You could just make the new tab show the home url by default.
>>
>> It already does.
>
> LOL :D
>
> FWIW: I've not yet seen the new tab button in action as it's always been 
> disabled in the Sugar builds I've tried due to the (I think) version 
> dependancy crash on tab close bug. Still, 'add tab' is not really a great UI 
> for getting to the home page, if that's what deployments are asking for, so I 
> think a home button and some free up of toolbar space is still needed.

I'm working on the tab crashing bug (when I can find the time) and it
seems to be a bug in hulahop and maybe one in Browse too. I'm hoping
I'll get it fixed soon enough.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Home button in browse - toolbar images

[Lucian Branescu]

2010/10/19 NoiseEHC :
> You could just make the new tab show the home url by default.

It already does.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RELEASE] Browse-119

[Lucian Branescu]

Thanks a lot.

I'll do a new release after I fix the tab close crash.

On 19 Oct 2010 14:41, "Gonzalo Odiard"  wrote:

I have commited a patch to solve the problem when you quit from the activity
and there are not a valid url active.

Gonzalo

> > I have two interesting traces. Have not checked the when they occur that
> is
> > > why I do not ope...
>
> > ___
> > Sugar-devel mailing list
> > sugar-de...@lists.sug...
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RELEASE] Browse-119

[Lucian Branescu]

On 15 October 2010 17:15, Simon Schampijer  wrote:
> On 10/15/2010 12:30 AM, Lucian Branescu Mihaila wrote:
>>
>> == Source ==
>>
>>
>> http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-119.tar.bz2
>>
>> == News ==
>>
>> This is a bugfix release.
>>
>> * Release 119 (Lucian Branescu Mihaila)
>> * generate preview image for downloaded images (SL#1106) (Gonzalo Odiard)
>> * Fix history on resume. The code is a bit hacky because of xulrunner
>> limitations. I plan to make this code nicer when we move to webkit. (Lucian
>> Branescu Mihaila)
>> * Simon Schampijer's patch to fix autocomplete functionality for the
>> address. (Lucian Branescu Mihaila)
>> * fix #8857 - Browse fails to download some files with non-ascii
>> characters (Gonzalo Odiard)
>
> I have two interesting traces. Have not checked the when they occur that is
> why I do not open a ticket (yet).

They're probably introduced by the recent patch to fix the position in
the history after resume. Please check if the history is restored
correctly.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Read: focus after launching

[Lucian Branescu]

On 14 October 2010 09:38, Sascha Silbe
 wrote:
> Excerpts from Simon Schampijer's message of Wed Oct 13 12:45:09 +0200 2010:
>
>> when working on the issue in Read that the dpad keys do not work
>> directly when in ebook mode [1], I postulated that Read when it comes up
>> should always grab the focus on the view so scrolling using the arrow
>> keys is directly possible.
>
> +1
> This is quite annoying (especially so since I usually scroll using the
> cursor keys, not a pointing device). I consider it a bug, but haven't
> bothered reporting it yet since there were more important ones (not
> working at all on recent distros for a start).
>
> Like Daniel I think that all activities (or all applications for that
> matter - I have the same problem with non-Sugar applications as well)
> should start with a sensible focus selected.
>
> We should check where focus gets assigned by default in activities that
> don't set it explicitly. Depending on the outcome (e.g. if it's in the
> tool bar by default), setting the focus in
> sugar.activity.activity.Activity.set_canvas() might be a good idea.

+1 on adding this to Read, don't know about other activities.

I'll do it as soon as I get time to fix Read.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Home button in browse - toolbar images

[Lucian Branescu]

On 14 October 2010 19:47, Gary Martin  wrote:
> Hi Gonzalo,
>
> On 5 Oct 2010, at 20:32, Gonzalo Odiard wrote:
>
>> Gary:
>> Here are the screenshots.
>> I comented a check of cairo version to add the tabs button.
>>
>> toolbar-browse-0.90.png and  toolbar-browse-0.84.png are with the emulator 
>> at 1200x900
>>
>> browse-90-in-sugar-emulator.png and browse-90-in-emulator-without-tabs.png 
>> are the worst case, sugar-emulator by default.
>> I don't know if is a real case.
>
> I've tinkered with Browse on an XO-1 to fake the extra home and tab button so 
> we are looking at our most likely common usage environment (as XO-1/1.5 folks 
> upgrade Sugar). The stop button does not fall off the end in this case, 
> though the search field is much smaller than I'd like to be honest. As an 
> emergency stop gap before we can code the reload/stop icon to move into the 
> URL input location (as per the clear icon in Sugar search fields), it is at 
> least a feasible option.
>
> FWIW under Simon's 0.90 F14 XO-1 builds the add new tab icon is auto disabled 
> (due to some other tab/api bug avoidance), so there is a at least little more 
> space for the location field.
>
> What is the target deployment you have in mind? One of the Dextrose builds?
>
> Note: I think Lucian mentioned he might be considering making the add new tab 
>  icon into a sub toolbar reveal, so that he has space for the add, remove, 
> next, last tab features (see Terminal for the example tab control use case). 
> If he is really considering this soon ;) then it might be better to move the 
> add new tab icon over to where I have placed the go-home icon, and move the 
> go-home icon over to where the add tab icon is placed (so the primary toolbar 
> icons with sub-toolbars are all together on the left).

I'd swap them anyway, Home makes sense to be next to Back/Forward.
However, I'm really not satisfied with the amount of space left for
the URL bar. I could maybe add reload and home in a toolbar, or add a
small stop/reload button inside the URL bar (but I'm not sure such
useful features should be hidden so well).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] Browse-119

[Lucian Branescu Mihaila]

== Source ==

http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-119.tar.bz2

== News ==

This is a bugfix release.

* Release 119 (Lucian Branescu Mihaila)
* generate preview image for downloaded images (SL#1106) (Gonzalo Odiard)
* Fix history on resume. The code is a bit hacky because of xulrunner 
limitations. I plan to make this code nicer when we move to webkit. (Lucian 
Branescu Mihaila)
* Simon Schampijer's patch to fix autocomplete functionality for the address. 
(Lucian Branescu Mihaila)
* fix #8857 - Browse fails to download some files with non-ascii characters 
(Gonzalo Odiard)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Status of Read activity (was: Re: Read Activity on Fedora 14 / SoaS v4)

[Lucian Branescu]

On 9 October 2010 15:28, Bernie Innocenti  wrote:
> On Sat, 2010-10-09 at 14:08 +0100, Lucian Branescu wrote:
>> > Who is the Read maintainer these days? AUTHORS still says Sayamindu,
>> > but AIUI he stopped working on Sugar stuff.
>>
>> Then I could probably use commit rights on Read mainline.
>
> Morgan Collet is still the owner of the read project on
> git.sugarlabs.org, but he's unlikely to work on it any more.
>
> Would you like to become the new owner?

If you're sure he won't work on it anymore, sure. But I just need write access.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Status of Read activity (was: Re: Read Activity on Fedora 14 / SoaS v4)

[Lucian Branescu]

On 9 October 2010 14:01, Sascha Silbe
 wrote:
> Excerpts from Lucian Branescu's message of Tue Sep 28 22:34:01 +0200 2010:
>
>> Epub support is not complete, you can see epubs, but none of the
>> toolbars work. [...]
>
> FWIW, I'd much rather see a working, but stripped-down Read upstream
> and in all distros than a working, stripped-down one in Fedora and a
> theoretically complete, but totally broken one everywhere else.

I was going to have a look at it this weekend, rebasing my partial
port shouldn't be too much trouble.

>> Also, my work was on a somewhat old Read. I was hoping Read's
>> maintainer would use my branch to port mainline, with whatever design
>> for the epub view the maintainer considered a good idea.
>
> Who is the Read maintainer these days? AUTHORS still says Sayamindu,
> but AIUI he stopped working on Sugar stuff.

Then I could probably use commit rights on Read mainline.

> Sascha
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Proposal of dotted activity version number

[Lucian Branescu]

On 7 October 2010 21:54, Gonzalo Odiard  wrote:
> Ticket with the start of implementation:
>
> http://bugs.sugarlabs.org/ticket/2425
>
> Gonzalo

I'm not sure which way would be best, but I would choose either a very
simple solution (just dotted numbers, no alphanumerics) or a
tried-and-tested solution i.e. carbon copy of debian/fedora/gnome apps
versioning.

In any case, something more expressive than an integer is needed and
I'm all for it.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse SL#1106, OLPC#8857: Re: Help with pending reviews

[Lucian Branescu]

On 6 October 2010 20:19, Sascha Silbe  wrote:
> [Moving this to sugar-devel as I don't see any need to keep it private]
>
> Excerpts from Simon Schampijer's message of Tue Oct 05 14:58:24 +0200 2010:
>
>> #1106 Browse: No preview in Journal for downloaded image
>> https://patchwork.sugarlabs.org/patch/273/
>>
>> I checked the pixbuf API and there is only composite-color-simple but in
>> the end you need two buffers here as well. I think what we have is
>> absolutely fine now. So if you don't object I would like Gonzalo to push
>> it, so we can land it in 0.84 as well.
>>
>> #8857 - Browse fails to download some files with non-ascii characters
>> https://patchwork.sugarlabs.org/patch/267/
>>
>> This one looks good to me, too. I looked at the patch Tomeu already did,
>> and this one just does the same thing. I think we can land that one, too.
>
> OK, then let's land both patches now (unless Lucian vetoes), but keep
> the tickets open so we can give a closer look later.

Fine by me. Will you do it Sascha, or shall I?

> Please fix the summaries before pushing. E.g.:
>
> fix downloading files with non-ASCII characters (OLPC#8857)
> generate preview image for downloaded images (SL#1106)
>
>
> Thanks for taking a look, Simon!
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Autocomplete functionality for the address does not work #2406

[Lucian Branescu]

On 6 October 2010 15:26, Sascha Silbe
 wrote:
> Excerpts from Simon Schampijer's message of Wed Oct 06 15:31:07 +0200 2010:
>
>> Hmm, Lucian was to quick.
>
> Hehe. No problem; I don't think this particular patch is going to
> matter when hunting down some issue and there's enough information
> in the description, even if just through an indirection (bug tracker).
> I just want to make sure we move in the right general direction. Good
> commit messages are getting more important as the number of contributors
> increases since no single person will have an overview of all the code
> (changes) anymore.
> This is why I pester new contributors and core developers alike with my
> complaints about commit messages.

Yes, it's a good thing you do keep pestering people. And I should know
better, too.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Autocomplete functionality for the address does not work #2406

[Lucian Branescu]

On 6 October 2010 14:31, Simon Schampijer  wrote:
> On 10/06/2010 03:23 PM, Simon Schampijer wrote:
>>
>> On 10/06/2010 03:20 PM, Sascha Silbe wrote:
>>>
>>> Excerpts from simon's message of Wed Oct 06 13:57:20 +0200 2010:
>>>
 see as well #2291 for more info. This one is important for 0.90.
>>>
>>> A bit more background information would be nice. A one-line summary
>>> of the analysis in #2291 (i.e. input vs. screen, sub-pixel vs. whole-
>>> pixel coordinate systems) would suffice.
>>> Also the summary should be more "active" (e.g. "fix address completion").
>>> Please adjust these before pushing. Thanks!
>>>
>>> Acked-By: Sascha Silbe
>>>
>>> Sascha
>>
>> Thanks for the review. Will address your comments.
>>
>> Regards,
>>     Simon
>
> Hmm, Lucian was to quick.
>
> Lucian you should leave the ticket number in the comment. Actually, you
> should probably take it as is unless there is a reason to not do so.
> 'git-am' will do so for you.

I don't think git-am works with gmail.

> http://git.sugarlabs.org/projects/browse/repos/mainline/commits/e8130523d74e24be64362c723a9ebed1087fc521
>
> Btw, the other commits were all intended to go on master and sucrose-0.90?
> You might want to branch off at this stage [1], if you have things that are
> not intended to land in 0.90.
>
> Regards,
>   Simon
>
> http://wiki.sugarlabs.org/go/Development_Team/Release#Branching

There's no patches I wanted to apply that I wouldn't want in 0.90.
Should I branch anyway?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Autocomplete functionality for the address does not work #2406

[Lucian Branescu]

On 6 October 2010 14:20, Sascha Silbe
 wrote:
> Excerpts from simon's message of Wed Oct 06 13:57:20 +0200 2010:
>
>> see as well #2291 for more info. This one is important for 0.90.
>
> A bit more background information would be nice. A one-line summary
> of the analysis in #2291 (i.e. input vs. screen, sub-pixel vs. whole-
> pixel coordinate systems) would suffice.
> Also the summary should be more "active" (e.g. "fix address completion").
> Please adjust these before pushing. Thanks!
>
> Acked-By: Sascha Silbe 
>
> Sascha

I've already applied it as the change was minor. I'll be more thorough
in the future :)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] Browse-118

[Lucian Branescu Mihaila]

== Source ==

http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-118.tar.bz2

== News ==

Mostly just translations.

* Release 118 (Lucian Branescu Mihaila)
* Commit from Sugar Labs: Translation System by user mschlager.: 29 of 30 
messages translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user thangam.ar...@gmail.com.: 
29 of 29 messages translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user Myckel.: 30 of 30 messages 
translated (0 fuzzy). (Pootle daemon)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] about reader

[Lucian Branescu]

On 29 September 2010 14:08, Gabriel Eirea  wrote:
> Hi:
>
> I'm replying to the list for more feedback. Please see below.
>
> 2010/9/29 Lucian Branescu :
>> On 29 September 2010 13:24, Gabriel Eirea  wrote:
>>> Hi Lucian:
>>>
>>> I've seen you are actively working on the Read activity. I am from
>>> ceibalJAM in Uruguay and we have a request for certain features and I
>>> would like to know your opinion about them. We may find a volunteer
>>> here to work on them, and maybe we can get some funding but it's still
>>> a remote possibility.
>>>
>>> The request comes from an editor that donated an ebook in pdf for
>>> Ceibal and finds it difficult to read in the current version of Read.
>>
>> Hi.
>>
>> I'm not a Read maintainer, I just lent a hand to fix Read temporarily.
>> I'm one of the maintainers of Browse, so my priorities are there. I
>> don't mean to discourage you from asking me things about Read and I
>> still intend to help out with Read if I find the time, I just wanted
>> you to know my position.
>>
>> You should also post this to the mailing list, others may have
>> better ideas than me. You can just add the mailing list email to the
>> CC when you reply.
>
> OK, thank you Lucian.
>
>>>
>>> The requested features are:
>>>
>>> - possibility to include a floating menu for navigation
>>
>> No other activity has done this before afaik and I'm not sure the
>> Sugar UI guidelines. I also don't know how resource intensive this
>> would be, but it may slow down scrolling. I believe keyboard
>> shortcuts, the XO game buttons and locking the navigation toolbar are
>> better solutions (the latter can already be done by clicking the
>> navigation toolbar button).
>
> Apparently this is a pdf feature that has been used before by the
> editors of this book before. The idea is to have a button for the
> index, the main sections, etc. always visible on top or bottom.

As I said, right now you can click the button for the navigation
toolbar and the toolbar will no longer hide when you move the pointer
away. Is that acceptable?

>>> - possibility to call one pdf file from inside another
>>
>> You mean URLs to other PDFs? The way this might work would be to
>> download the PDF from that URL to the Journal and offer the user the
>> option to open it from the Journal (in Read). As of right now, the
>> Read activity has no internet access and I don't know if it's a good
>> idea to add this feature. Others may be able to say more on this
>
> This feature would be needed to speed up the loading of
> graphics-intensive books. I imagine there would be a bundle with
> several pdf files that would have links among them. I don't know how
> to make this compatible with the journal.

I think would be better achieved with a single PDF or a single EPUB
file. To open multiple PDFs anyway, Read might be able to open a .zip
file and open PDFs/EPUBs from there, but again I'm not sure it's a
good idea r.e. UI guidelines.

>>> - possibility to call a web page from inside the pdf
>>
>> This scenario has been discussed before, with no useful conclusion.
>> The way security works in Sugar, activities are not allowed to open
>> other activities. An exception could possibly made for the browser or
>> the Sugar API could be extended so that activities declare what URIs
>> they accept to open (e.g. http:, file:, apt: magnet:, etc.)
>
> Apparently this would be a very useful feature for learning ebooks,
> since they would like to have links to webpages with further
> information on certain topics.

This feature needs more discussion - both UI design and implementation-wise.
At the moment, users can copy links and paste them in Browse.

>>> - add zoom by paragraph to improve legibility with small fonts
>>
>> Do you mean automatically zooming on a certain paragraph? I don't know
>> if evince (the backend we use for displaying PDFs) is capable of this,
>> I'd have to check.
>
> Yes, "automatically zooming" would mean for example using the
> navigation keys to select next/previous paragraph and showing the
> selected paragraph with a larger font.

I see. If evince has support for this, it won't be too hard to
implement. If not, it might be quite hard.

>>> - possibility to have different page sizes inside a document
>>
>> Do you mean pages of different sizes? How would these sizes be
>> determined? Do you mean zooming pages independantly?
>
> The page sizes would be defined at the time of

Re: [Sugar-devel] Read Activity on Fedora 14 / SoaS v4

[Lucian Branescu]

On 28 September 2010 21:26, Simon Schampijer  wrote:
> On 09/28/2010 10:14 PM, Sascha Silbe wrote:
>>
>> Excerpts from Simon Schampijer's message of Tue Sep 28 21:00:22 +0200
>> 2010:
>>
>>> Ok, Lucian just explained me the rationale behind the Fedora version.
>>> Version 79 is coming from the evince-2-30 branch [1]. And the bundle is
>>> from his personal repository [2].
>>
>> Can somebody merge that in mainline and release it, please? Otherwise
>> Read on distros other than Fedora will remain broken, as will Read in
>> sugar-jhbuild.
>>
>> Sascha
>
> Lucian said that the work has not been completed. Lucian can you comment
> what is missing? If you can not do it maybe someone else can go for it.
>
> Regards,
>   Simon
>

Epub support is not complete, you can see epubs, but none of the
toolbars work. The old Read had a wrapper built around pywebkitgtk
that exposed an API similar to libevview <2.28. Because the API of
libevview >=2.30 is so different, I didn't get around to porting the
webkit wrapper. In fact, I'm not even sure it's a good idea.

Also, my work was on a somewhat old Read. I was hoping Read's
maintainer would use my branch to port mainline, with whatever design
for the epub view the maintainer considered a good idea.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] implements #1106 - Browse: No preview in Journal for downloaded image

[Lucian Branescu]

Sorry for the vry long time I left this in patch purgatory. I haven't
had internet access for quite a while.

Sacha, thanks for picking it up.

On 15 Sep 2010 11:58, "Simon Schampijer"  wrote:

Hi Gonzalo,

thanks for the new patch. Would be good to tell in a few words what you
did change to the previous one, like: "I addressed all concerns." or
"That one I did not address since..."

Regards,
Simon


On 09/14/2010 08:06 PM, godi...@sugarlabs.org wrote:
> From: Gonzalo Odiard
...

___
Sugar-devel mailing list
sugar-de...@lists.sugarlabs...
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Home button in Browse

[Lucian Branescu]

On 6 September 2010 16:53, Bert Freudenberg  wrote:
>
> On 06.09.2010, at 17:50, Sascha Silbe wrote:
>
>> Excerpts from Simon Schampijer's message of Mon Sep 06 16:25:03 +0200 2010:
>>
>>> I would say, adding a button that brings you back to the defined default
>>> page would be a good addition. There is even an icon in artwork already
>>> (attached) :)
>>
>> Actually I'm surprised it isn't already in Browse. We could add a new
>> Palette (with some "location" / URI related icon) containing reload and
>> go-home. Both are used rarely enough that we don't need them in the
>> main toolbar.

Yeah. And I should probably make a new toolbar with all the tab
buttons that Terminal has.

>
>
> Go-home would be the button I press most often, to counteract auto-resuming.
>
> - Bert -

Wouldn't a clearer explanation of auto-resuming in the UI be a better
fix to this particular issue?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Home button in Browse

[Lucian Branescu]

On 6 September 2010 15:25, Simon Schampijer  wrote:
> Hi,
>
> I can well imagine there had been several discussions about this before,
> even so a quick search of the archives did not reveal something:
>
> Deployment(s) have been asking how to go back to the home page (OLPC start
> page / Sugar Labs start page) in the Browse activity. I think in 0.84, as we
> resume by default, we see more learners to have problems with that, because
> in 0.82 we did start a new session when clicking on the activity icon, hence
> the Browse activity came up with the starting page in most cases.
>
> I would say, adding a button that brings you back to the defined default
> page would be a good addition. There is even an icon in artwork already
> (attached) :)
>
> What do others think?
>
> Thanks in advance for your feedback,
> Simon

Sounds good to me. I'm just a bit worried that the toolbar is getting
ever more crowded, now with new tabs and whatnot.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] view source

[Lucian Branescu]

You can't customise it, but you can offer a document to be viewed alongside
the python source. Check how Browse does it.

On 30 Aug 2010 22:13, "Erik Blankinship"  wrote:

How do you customize what is shown when "view source" is selected for an
activity?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] GSoC question

[Lucian Branescu]

On 25 August 2010 19:44, samir menon  wrote:

> So I have hearing a lot about Google Summer of Code on the mailing list
> (specifically,, Dinko Galetic's project!) What happens when they finish
> their project? Do the projects (read: Dinko's project) get submitted as a
> patch for the respective activity (read: Pippy)? Or is the project just for
> their personal learning experience? I checked Dinko's email, but the
> attached files didn't seem to be written in python...Are theyhosted
> somewhere else?
>
> Any clarification would be very much appreciated,


It is up to the individual maintainers whether or not they merge the work
done by students over GSoC.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Bump Python dependency from 2.5 to 2.6

[Lucian Branescu]

On 25 August 2010 15:23, Simon Schampijer  wrote:
> Hi,
>
> raised during the review of [1] some code was relying on Python 2.6
> (with open(COUNTRY_CODES_PATH) as codes_file:).
>
> Is it sane to switch to this Python version for the Sugar platform? More
> readings on what is new in 2.6 at [2]. Python 2.6 is available in F11,
> hence 0.84. Not sure for the other distributions...
>
> Objections, comments?

If depending on 2.6 isn't desirable, we can use __future__ imports.
(from __future__ import with_statement).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse-115 stops when pop-up tab closes

[Lucian Branescu]

On 18 August 2010 03:06, Christoph Derndorfer
 wrote:
> On Sat, Aug 14, 2010 at 8:54 AM, Lucian Branescu 
> wrote:
>>
>> Afaict, this isn't a bug in Browse, but in sugar.activity.Activity. I
>> also can't find any evidence in the logs that it segfaults. I'm afraid
>> unless I can reproduce it I can't do anything.
>>
>> Could you save the HTML page that opens a new window (tab), with
>> javascript and everything? That may help me reproduce it.
>
> Sorry, I missed that message of yours...
>
> Would a Firefox -> Save complete page copy be good enough for this purpose?

That should be enough to reproduce it, yes.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] (no subject)

[Lucian Branescu]

On 15 August 2010 15:38,   wrote:
> HI all,
> When we start sugar-emulator in ubuntu , The title text in emulator window
> shows [Xephyr on 30.0].Now , after going through code and other resources
> what i deducted is that Xephyr is window/session manager which we uses to
> run sugar on Ubuntu.Now when i tried to find the source for text in code
> ,but I was directed towards xpehyr which means that the text in window is
> given by Xephyr . Now , i was wondering if there is any way so that we
> could indiacate that sugar emulator session was in progress.Like
> replacing/adding text in title bar with Sugar-something ?

Xephyr is the X server used by sugar-emulator to run Sugar in a
window, rather than fullscreen.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Appropriate to call myself "senior developer"?

[Lucian Branescu]

On 15 August 2010 05:19, Bernie Innocenti  wrote:
> El Sat, 14-08-2010 a las 12:28 +0200, Sascha Silbe escribió:
>> Hi!
>>
>> Would anyone dislike me calling myself "senior developer and system
>> administrator at Sugar Labs" in my CV or consider it inappropriate? If
>> so, what other description would you recommend?
>
> +1 from me...
>
> ...as long as I can be "Senior Wizard Extraordinaire and Überhaxc0r at
> Sugar Labs and everywhere else" :-)

Calling ourselves wizards would be interesting.

And Silbe, +1.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse-115 stops when pop-up tab closes

[Lucian Branescu]

On 14 August 2010 07:01, Tabitha Roder  wrote:
> On 12/08/2010, Christoph Derndorfer  wrote:
>
>> Okay, submitted the bug which should hit Sascha Silbe's inbox for moderation
>> right about now.
>
> http://bugs.sugarlabs.org/ticket/2155
>
> We have this problem too with os300py and the "lavaspot" wifi hotspot
> login in Samoa.
>
> Reported badly privately last week (little internet at that time). I
> will grab a tcpdump of it happening and attach to ticket.
>
> The quit is /fast/ like it core dumped. I tried messing with quotas to
> get a core but was unsuccessful. Tips? Where would a core be dropped?
> If the process does die untidily, where is this fact logged? Where
> does it's stderr go? stdout and stderr go to the log file, so it
> should  say signal 11" in the log if it seg faulted, right?
>
> I can reproduce for the next 24 hours and have good net access once
> again, if there is something I can do to diagnose, please let me know.
> (we leave samoa tomorrow).

Afaict, this isn't a bug in Browse, but in sugar.activity.Activity. I
also can't find any evidence in the logs that it segfaults. I'm afraid
unless I can reproduce it I can't do anything.

Could you save the HTML page that opens a new window (tab), with
javascript and everything? That may help me reproduce it.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse-115 stops when pop-up tab closes

[Lucian Branescu]

On 12 August 2010 19:21, Christoph Derndorfer
 wrote:
> On Tue, Aug 10, 2010 at 11:39 PM, James Cameron  wrote:
>>
>> If this is the error that is killing Browse-115, it appears to be a
>> problem with get_preview in Sugar.  What version of Sugar is it?
>
> Sugar 0.88
> On Wed, Aug 11, 2010 at 4:07 AM, Lucian Branescu 
> wrote:
>>
>> This exception doesn't seem related to the cairo bug. I'll try to
>> reproduce it on my XO. Please file a bug report if you haven't
>> already.
>
> Should I file the bug with  Sugar Labs or OLPC?

Sugar Labs http://bugs.sugarlabs.org. If you want, I can file the bug for you.

I haven't been able to reproduce it so far. I'll have a look at Horde
to see how they authenticate.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse-115 stops when pop-up tab closes

[Lucian Branescu]

This exception doesn't seem related to the cairo bug. I'll try to
reproduce it on my XO. Please file a bug report if you haven't
already.

> Cairo version:
>
> cairo-1.8.8-1.fc11.i586
>
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/site-packages/gtk-2.0/gobject/__init__.py", line
> 108, in obj_set_property
>     prop.setter(self, value)
>   File "/usr/lib/python2.6/site-packages/sugar/activity/activity.py", line
> 365, in set_active
>     self.save()
>   File "/usr/lib/python2.6/site-packages/sugar/activity/activity.py", line
> 600, in save
>     preview = self.get_preview()
>   File "/usr/lib/python2.6/site-packages/sugar/activity/activity.py", line
> 548, in get_preview
>     width, height = pixmap.get_size()
> AttributeError: 'NoneType' object has no attribute 'get_size'
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Killing activities when memory gets short

[Lucian Branescu]

2010/8/10 NoiseEHC :
>
>> We used to do that, the problem is that we don't control our platform
>> as Google controls Android and you need to make sure that resources
>> that need to be specific of each child process aren't shared (dbus and
>> X connections, etc).
>>
>> I'm personally more interested in reducing the amount of resources we
>> need to start activities (which is quite insane right now), but
>> sharing more of those resources sounds like a good idea to me.
>>
>
> Since I spent quite a bit of time analyzing the Python runtime here is my
> conclusion, maybe it will make wasting all that time less painful.
>
> First, most of the memory consumed by an activity is the process heap. While
> the Python runtime and native libraries are shared among processes, the heap
> is not. Even if you fork processes it will not work because reference
> counting will dirty the shared pages and my instinct tells me that just
> loading a Python source file will reference almost all the shared pages
> because they are mostly used to store already loaded modules. What I finally
> did not do is to actually check the hypothesis that most of the heap is
> filled by strings which are the identifiers in the loaded Python modules. My
> goal was to somehow make identifiers constants and just readonly-mmap them
> into the process (replace the pathetic .pyc loading mechanism). Note that my
> plan was just a little subset of the .jar -> .dex converter.
>
> Second, Python has a special memory manager which works with buckets so
> there are separate heaps for different object sizes. Somehow this special
> memory manager is turned off in release mode and it uses the standard C heap
> for some reason. Either it is a bug or just it turned out to be faster (more
> work was put into glibc) I do not know, but handling the linked free list
> can dirty shared pages as well or I am just mistaken...
>
> Third, the fact that Python is a dynamic language does not help any
> prefetching or memory sharing. I am not too convicted either that this
> dynamic nature is used at all in the Sugar codebase but you know I cannot
> program in Python and frankly I do not feel the need to learn another
> language. Just now, at my age of 34, I finally gave up and learned LISP
> (more specifically clojure) and I hope that it will be the last programming
> language I will have to learn (other than assembly languages of course)...
> :) Now this point is interesting because if you thought that the Dalvik VM
> could run the Sugar codebase via Jython then it just will not work. The
> Dalvik VM just cannot load .jar files and Jython just generates them on the
> fly because of the dynamic nature of Python.
>
> Fourth, moving Python (theoretically) to a GC environment (instead of
> reference counting) also would not work if the GC is compacting because it
> would also dirty the shared pages. So a mark and sweep nonmoving GC with
> separately stored "visited" bits is the only feasible solution. Now guess
> what the Dalvik VM does?
> For more info (45 min + questions):
> http://www.youtube.com/watch?v=ptjedOZEXPM
>
> So *my* conclusion is that solving this sharing problem is *very* hard. I am
> not sure that simply translating all activities from Python to Java would
> take more time.
>
> Another interesting thing is that meantime the unladen-swallow project
> progresses (just more slowly than planned). Their plan is to make it the
> default Python runtime so if it will happen (I cannot comment on that) then
> the Python VM will use even more memory (though it will be faster) so Sugar
> will be even less interesting on the myriad of low spec cheap ARM tablets
> which will flood the market soon.
>
> I think that is all I can say about this subject so I just finish it here.

The PyPy project has a fully-featured python 2.5 interpreter that has
much lower memory usage and a proper GC (so less dirty pages). They
also have an x86 JIT which makes it much faster than CPython, at the
cost of a bit of memory (still less than CPython). The only issue
right now is extension support: ctypes is fully supported, but
C/Python extension support is not complete by far.

As for Jython on Android, Jython has a Java bytecode JIT. It should be
entirely possible to write a dalvik backend to this JIT.

So not only would rewriting everything to Java be a huge step
backwards, but it would also be more work.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse-115 stops when pop-up tab closes

[Lucian Branescu]

Yes, it is a bug.

It has been observed that under certain versions of cairo, Browse with tabs
crashes. V115 checks for this and disables tabs if such a version is
detected. It's possible that other versions of cairo are problematic, too.

Please attach Browse's log and report your cairo version, I'll check it out
tomorrow.

On 10 Aug 2010 21:33, "Chris Ball"  wrote:

Hi,


> I have been consistently able to reproduce this on my XO-1
> running build 353pyg and Brows...
Quitting the entire activity in response to (presumably) a javascript
statement can only be a bug, in my opinion.

Thanks,

- Chris.
--
Chris Ball   
One Laptop Per Child
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Killing activities when memory gets short

[Lucian Branescu]

On 9 August 2010 14:44, NoiseEHC  wrote:
>
>> Sugar has a similar mechanism. From the Low-level Activity API docs:
>>
>> org.laptop.Activity.SetActive(b: active)
>> Activate or passivate an activity. This is sent when switching activities, 
>> there is only one active activity at a time, all others are passive. A 
>> passive activity must immediately release resources like sound, camera etc. 
>> Also it should prepare for being killed without warning at any time in the 
>> future (see OOM) by auto-saving to the datastore.
>>
>> The issue is that it's hard to estimate how many Sugar activities actually 
>> do this, because until now they usually have not been killed (*). Might be 
>> an interesting test - just randomly kill activities from Terminal and see if 
>> they resume correctly ...
>>
>> Maybe "good" activities could "volunteer" to be shut down first. Or "bad" 
>> activities would have to "beg" to live a little longer. Might just take an 
>> entry in the activity.info file.
>>
>
> It will not work, because the application startup time is horrible on
> the XO. The Dalvik VM goes a lng way to have fast application
> startup and to share most of the memory among applications (the Zygote
> process does this). Actually that was the exact thing I tried to do with
> the Python VM. Just at the exact time when I started to hack Python I
> have seen the Google I/O video about the Dalvik VM and thought that
> duplicating that work would have been a waste of time. So if you wanna
> fix the Python VM, good luck, but you know it is already been coded...
> :) Without fast activity startup, killing activities will be a horrible
> user experience. Maybe not that bad as a totally unresponsive XO though.

It wouldn't be a duplication of efforts since Dalvik does not run
Python and it is unlikely that it ever will. Perhaps a simple fork
zygote for python wouldn't be that hard to accomplish in the sugar
shell.

>
>> (*) Apple seems to have foreseen this "developer psychology" issue and 
>> actually killed all apps in the first three iterations of its iOS. So apps 
>> had to implement this state saving if the user was to be able to continue 
>> after leaving an app. Would be interesting to know how many Android apps 
>> actually implement it.
>>
>
> All of them. If an Android application does not implement it correctly
> then there will be big problems while switching apps and while
> navigating among application screens.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Killing activities when memory gets short

[Lucian Branescu]

On 9 August 2010 11:25, Bert Freudenberg  wrote:
> On 09.08.2010, at 01:21, John Gilmore wrote:
>
>>> As long as activities are saving and restoring properly it could be
>>  made pretty much transparent to the user. Of course that's easier
>>  said then done...
>>
>> Android has a whole mechanism for this:
>>
>>  http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html
>>
>> That explains the problem, but doesn't explain the Android answer
>> to it, which is here:
>>
>>  http://developer.android.com/guide/topics/fundamentals.html
>>
>> The section "Component Lifecycles" gives the summary.  They call each
>> app's onPause() method when it is obscured from visibility on the
>> screen, and that method is responsible for recording everything the
>> app needs to restart itself and get back to the same screen display
>> (what file it was working on, how far down the file it was, etc).
>> Then, any process whose onPause() method has been called is considered
>> a cache, and can be killed without warning by the kernel.
>>
>> (I'm not advocating using this system -- I've only barely been
>> exposed to it.  But it's useful to see how others have solved the
>> problem you're facing, before making your own solutions.)
>
> Sugar has a similar mechanism. From the Low-level Activity API docs:
>
> org.laptop.Activity.SetActive(b: active)
> Activate or passivate an activity. This is sent when switching activities, 
> there is only one active activity at a time, all others are passive. A 
> passive activity must immediately release resources like sound, camera etc. 
> Also it should prepare for being killed without warning at any time in the 
> future (see OOM) by auto-saving to the datastore.
>
> The issue is that it's hard to estimate how many Sugar activities actually do 
> this, because until now they usually have not been killed (*). Might be an 
> interesting test - just randomly kill activities from Terminal and see if 
> they resume correctly ...
>
> Maybe "good" activities could "volunteer" to be shut down first. Or "bad" 
> activities would have to "beg" to live a little longer. Might just take an 
> entry in the activity.info file.
>
> - Bert -
>
> (*) Apple seems to have foreseen this "developer psychology" issue and 
> actually killed all apps in the first three iterations of its iOS. So apps 
> had to implement this state saving if the user was to be able to continue 
> after leaving an app. Would be interesting to know how many Android apps 
> actually implement it.

On Android, all (good) apps always save their state. There may be some
bad ones, but all the ones I've used do it properly. Since apps are
made out of activities (views) connected by intents, all the
activities in an app save state. When starting an app, the main
activity decides what to show (saved or new state) or it can switch to
another activity that was active when the app was killed.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Killing activities when memory gets short

[Lucian Branescu]

On 8 August 2010 20:51, Marco Pesenti Gritti  wrote:
> On 8 Aug 2010, at 20:38, Lucian Branescu  wrote:
>>>
>>> Imo a confirmation popup would become annoying very quickly. Also if the 
>>> user refuses, the kernel will have soon to kill an activity, which is worst.
>>
>> Activities already write_file when they lose focus, they could
>> write_file periodically or at least when warned of low memory.
>
> Yes, that's how I think it should work. Of course activities will need to do 
> a better work to save all the possible state, because we are closing without 
> user intervention.
>
>>
>>>
>>>> Apps like instant messaging(though I don't recall one for Sugar), would 
>>>> definitely need a definitive opt out, no?
>>>
>>> Yeah, that's where things get tricky :/ Same issue with a background music 
>>> player for example. Ideally we would just keep the connection open somehow 
>>> and close the whole UI, but that's going to get complex.
>>>
>>> As long as this causes just minor annoyances to the user (like being 
>>> disconnected or music stopping), I think it's probably something we don't 
>>> need to solve in the first iteration.
>>
>> Separating the activity from the service would help here. In the case
>> of music, MPD would use a lot less memory than one of its GUIs.
>
> Right, I was thinking to something along these lines too. I'm not sure how 
> the shell would enforce this policy though. Maybe we could allow the activity 
> processes to use a minimum amount of memory when it has been asked to close. 
> As I said, it gets complicated :)

An activity frontend to MPD could be killed following activity policy
and the MPD daemon itself would be killed following regular daemon
policy. Music would play after the activity dies and would only be
stopped if the MPD daemon is killed (which is less likely since it
uses very little memory).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Killing activities when memory gets short

[Lucian Branescu]

On 8 August 2010 20:33, Marco Pesenti Gritti  wrote:
> On 8 Aug 2010, at 18:40, Tiago Marques  wrote:
>> The idea of killing activities with the content closed seems ok but it would 
>> probably be a good idea to have a way to opt out of it for some apps. I'm 
>> thinking a PDF that may be left open on purpose to serve as reference to 
>> something, a browser window, etc.
>
> An opt out could be easily abused... In the PDF case the activity could be 
> closed and reopened under the hoods, without the user even noticing (well, 
> startup time aside).
>
>> Are you then proposing to use the LRU policy to do the killing? I'm thinking 
>> that a popup with a cancel tied to a timeout may be a good idea. Once it is 
>> not allowed to be killed, it should not try to again for the session, or at 
>> least for a very large increase in query time.
>
> Imo a confirmation popup would become annoying very quickly. Also if the user 
> refuses, the kernel will have soon to kill an activity, which is worst.

Activities already write_file when they lose focus, they could
write_file periodically or at least when warned of low memory.

>
>> Apps like instant messaging(though I don't recall one for Sugar), would 
>> definitely need a definitive opt out, no?
>
> Yeah, that's where things get tricky :/ Same issue with a background music 
> player for example. Ideally we would just keep the connection open somehow 
> and close the whole UI, but that's going to get complex.
>
> As long as this causes just minor annoyances to the user (like being 
> disconnected or music stopping), I think it's probably something we don't 
> need to solve in the first iteration.

Separating the activity from the service would help here. In the case
of music, MPD would use a lot less memory than one of its GUIs.

>
> Marco
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] Browse-117

[Lucian Branescu Mihaila]

Bugfix release, adds a missing tab icon.

Please test this and report back any issues with tabs, from functionality to 
design.
Note: tabs will disable themselves if you have a version of cairo that would 
crash Browse.

== Source ==

http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-117.tar.bz2
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] Browse-116

[Lucian Branescu Mihaila]

- keyboard shortcuts for back/forward/reload
- add CAcert
- user-visible tab support. Note that the tab support will disable itself if it 
detects cairo v >= 1.08.10

== Source ==

http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-116.tar.bz2
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Evince browser plugin

[Lucian Branescu]

Thanks. Rebasing to 2.28 shouldn't be that hard, but 2.30 has had
major API changes, so it would have to be ported.

For now we've left Browse PDF support for later since we're having a
lot of trouble getting anything working in the first place
(pywebkitgtk issues, no libsoup python binding, etc.)

On 28 July 2010 00:29, Marco Pesenti Gritti  wrote:
> Hi Lucian,
>
> sorry for the long delay, here is the git repository with the evince
> browser plugin.
>
> http://git.sugarlabs.org/projects/evince-browser-plugin
>
> The changes are on the plugin branch. It builds and seems to work fine
> for me in Lucid. Unfortunately it's still based on 2.25... I haven't
> tried rebasing to master, so I'm not sure how much work that would
> involve.
>
> Marco
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys

[Lucian Branescu]

On 27 July 2010 23:57, Bernie Innocenti  wrote:
> On Tue, 2010-07-27 at 18:21 -0400, C. Scott Ananian wrote:
>
>> This is a nicely decentralized mechanism for choosing identifiers
>> which are guaranteed by construction never to conflict.
>
> It is indeed a simple and nice scheme, but why is such uniqueness a
> desiderable feature when developers can--and in fact *do*--often
> distribute forks of existing activities?
>
> Lucian has just created a fork of Browse and ParaguayEduca has a fork of
> XoIRC and VncLauncher on its wiki. In all cases, the bundle_id was
> intentionally left unmodified to ensure upgrades would work.

Actually, after careful consideration I've rebranded Browse-webkit to Surf.

> (if the bundle_id were instead changed, funny things would happen when a
> user tries to install both bundles on the same machine).
>
>
>> If sugarlabs is willing to maintain a mechanism for ensuring
>> uniqueness, feel free to prepend org.sugarlabs to whatever activities
>> you have "registered".
>
> A good surrogate could be that no two activities with the same name can
> be uploaded to ASLO.
>
> Without a fancy scheme for signed bundles, nothing forbids people from
> distributing bundles with conflicting names from other sites, regardless
> of what uniqueness scheme gets chosen.
>
>
>> > For all other purposes, the bundle_id is just a string which could
>> > contain anything. The bundle_id "org.tuxpaint.sugar-is-lame" worked
>> > flawlessly for all this time.
>>
>> Yes, this identifier is childish, but conforms precisely to the rules
>> outlined above, which ensure its uniqueness.
>
> It's not actually conforming, it has hyphens! ;-)
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Retro resource management game, anyone remember?

[Lucian Branescu]

Globulation 2 is a currently maintained project and offers a nice take
on resource management.
http://globulation2.org/wiki/Main_Page

On 25 July 2010 18:37, Bernie Innocenti  wrote:
> El Sun, 25-07-2010 a las 02:25 +0100, Gary C Martin escribió:
>
>> Anyone else remember this?
>
> I played dozens of similar time-sinks, but none in particular that would
> match your description 100%... the oldest resource-management games I
> remember are:
>
>
> The Settlers (1993, Amiga)
> http://en.wikipedia.org/wiki/The_Settlers_(video_game)
>
> Populous (1989, Amiga)
> http://en.wikipedia.org/wiki/Populous
>
> M.U.L.E. (1983, C64)
> http://en.wikipedia.org/wiki/M.U.L.E.
>
> Dome Dweller (1984, C64, source code printed in a book)
> http://ready64.it/libri/scheda_libro.php?id_libro=55
>
>
> Not to mention Civilization and SimCity, probably the most popular and
> long-lived games of this genre.
>
> I think playing these games in moderation provides an important learning
> opportunity.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Browse-webkit] Changing its bundle_id

[Lucian Branescu]

I've rebranded Browse-webkit to Surf-115.
http://people.sugarlabs.org/lucian/Surf-115.xo

On 22 July 2010 19:03, Lucian Branescu  wrote:
> I was planning to simply pretend that Browse-webkit is a newer version
> of Surf. In a way it is, since they share some ancient git history :)
>
> So unless Bobby minds us using Surf's brand, we shouldn't need a new
> icon. Thanks for offering, though.
>
> On 22 July 2010 18:54, Gary Martin  wrote:
>> On 22 Jul 2010, at 17:26, Lucian Branescu  wrote:
>>
>>> If bobbyp agrees, I'll rebrand it to Surf until it gets merged to
>>> master. Would that be ok?
>>
>> Need a new svg icon, temp or otherwise? Happy to cook something up, similar 
>> to the old surf svg involving a breaking wave (I'd go for open circle inside 
>> breaking roller, rather than a circle with a roller inside).
>>
>> Regards,
>> --Gary
>>
>>> On 22 July 2010 17:24, Benjamin M. Schwartz  
>>> wrote:
>>>> On 07/22/2010 12:18 PM, Lucian Branescu wrote:
>>>>> In order to better test Browse-webkit, we'd need to package and 
>>>>> distribute it.
>>>>
>>>> If it isn't heavily tested and known to work perfectly, definitely don't
>>>> call it "Browse", and definitely don't use the same icon.  Browse is by
>>>> far the #1 most important activity, so we cannot accept _any_ regressions.
>>>>
>>>> --Ben
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Browse-webkit] Changing its bundle_id

[Lucian Branescu]

I was planning to simply pretend that Browse-webkit is a newer version
of Surf. In a way it is, since they share some ancient git history :)

So unless Bobby minds us using Surf's brand, we shouldn't need a new
icon. Thanks for offering, though.

On 22 July 2010 18:54, Gary Martin  wrote:
> On 22 Jul 2010, at 17:26, Lucian Branescu  wrote:
>
>> If bobbyp agrees, I'll rebrand it to Surf until it gets merged to
>> master. Would that be ok?
>
> Need a new svg icon, temp or otherwise? Happy to cook something up, similar 
> to the old surf svg involving a breaking wave (I'd go for open circle inside 
> breaking roller, rather than a circle with a roller inside).
>
> Regards,
> --Gary
>
>> On 22 July 2010 17:24, Benjamin M. Schwartz  wrote:
>>> On 07/22/2010 12:18 PM, Lucian Branescu wrote:
>>>> In order to better test Browse-webkit, we'd need to package and distribute 
>>>> it.
>>>
>>> If it isn't heavily tested and known to work perfectly, definitely don't
>>> call it "Browse", and definitely don't use the same icon.  Browse is by
>>> far the #1 most important activity, so we cannot accept _any_ regressions.
>>>
>>> --Ben
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys

[Lucian Branescu]

On 22 July 2010 17:49, Bert Freudenberg  wrote:
> On 22.07.2010, at 12:18, Lucian Branescu wrote:
>
>> I was thinking of changing
>> the bundle_id of Browse-webkit from 'org.laptop.WebActivity' to
>> 'org.sugarlabs.WebActivity', to allow both Browse to be installed and
>> working at the same time. However, this might confuse users yet again,
>> since they'd have their good old Browse along with a possibly broken
>> one.
>
> I have a similar problem. The bundle_id for Etoys is org.vpri.Etoys because 
> the activity was initially developed at VPRI. Now that VPRI is not involved 
> anymore we should change it to e.g. org.squeak.Etoys to reflect the new 
> organization.

If it doesn't bother you that vpri is in the bundle name and VPRI
themselves don't have a problem with it, I don't think you should
bother changing it. For example many activities are org.laptop.*, even
though they're now developed under Sugar Labs.

> Also, for some time I wanted to change the versioning scheme. I used to 
> increment the version number and release a new activity bundle whenever 
> something in the base system's etoys changed, even if there was no change to 
> the activity itself (the bundle is just a thin wrapper). That doesn't really 
> make sense. I was hoping Sugar's new "dotted-version" scheme would arrive in 
> time for this, but has it?

Then you could just not bump the activity version if it doesn't
change. Don't know about dotted versions.

> But what about existing Journal entries? They would still be tagged with the 
> old bundle id, though the mime type would identify them as Etoys projects. If 
> the old activity was uninstalled, would the new one automatically open those 
> entries?

Yes, it would open those entries if the mime types are correct. But
the updater would probably not update etoys if it had a different
bundle_id.

> - Bert -
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Browse-webkit] Changing its bundle_id

[Lucian Branescu]

If bobbyp agrees, I'll rebrand it to Surf until it gets merged to
master. Would that be ok?

On 22 July 2010 17:24, Benjamin M. Schwartz  wrote:
> On 07/22/2010 12:18 PM, Lucian Branescu wrote:
>> In order to better test Browse-webkit, we'd need to package and distribute 
>> it.
>
> If it isn't heavily tested and known to work perfectly, definitely don't
> call it "Browse", and definitely don't use the same icon.  Browse is by
> far the #1 most important activity, so we cannot accept _any_ regressions.
>
> --Ben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [Browse-webkit] Changing its bundle_id

[Lucian Branescu]

In order to better test Browse-webkit, we'd need to package and distribute it.

However, it is plagued with dependency issues. It requires pywebkitgtk
1.1.6 and webkitgtk 1.1.7, which aren't an option on fedora 11 without
breaking other things. pywebkitgtk has a bug
(http://code.google.com/p/pywebkitgtk/issues/detail?id=48) which makes
Browse-webkit segfault a lot. There are some features missing
(cookies, proper sugar sessions) because the lack of a libsoup python
binding and because of the lack of pywebkitgtk 1.1.7 + webkitgtk
1.1.14+.

Most of this could be solved by PyGI (if it works), but that isn't an
option on fedora 11 either.

Since replacing a working Browse with one that's likely to crash or at
least not have some features is a bad idea, I was thinking of changing
the bundle_id of Browse-webkit from 'org.laptop.WebActivity' to
'org.sugarlabs.WebActivity', to allow both Browse to be installed and
working at the same time. However, this might confuse users yet again,
since they'd have their good old Browse along with a possibly broken
one.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Browse: Add support for creating multiple tabs

[Lucian Branescu]

Could you please attach a patch against mainline master HEAD? (not
inline in the email)

Also, does it still crash?

On 1 July 2010 21:02, anishmangal2002  wrote:
> This patch adds support to create multiple tabbed windows
> in Browse. A tab may be added by either clicking the add tab
> ('+') icon in the activity toolbar or by pressing 'ctrl+t'.
>
> Signed-off-by: anishmangal2002 
> ---
>  icons/tab-add.svg |   12 
>  webactivity.py    |   17 +++--
>  webtoolbar.py     |   33 ++---
>  3 files changed, 49 insertions(+), 13 deletions(-)
>  create mode 100644 icons/tab-add.svg
>
> diff --git a/icons/tab-add.svg b/icons/tab-add.svg
> new file mode 100644
> index 000..c1457bd
> --- /dev/null
> +++ b/icons/tab-add.svg
> @@ -0,0 +1,12 @@
> + 'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'[
> +       
> +       
> +]> viewBox="0 0 55.125 55" width="55.125px" x="0px" xml:space="preserve" 
> xmlns="http://www.w3.org/2000/svg"; xmlns:xlink="http://www.w3.org/1999/xlink"; 
> y="0px">
> +
> +    
> +    
> +         fill="&fill_color;"/>
> +    
> +    
> +
> +
> \ No newline at end of file
> diff --git a/webactivity.py b/webactivity.py
> index d7d8651..877f182 100644
> --- a/webactivity.py
> +++ b/webactivity.py
> @@ -154,6 +154,7 @@ def _set_accept_languages():
>     logging.debug('LANG set')
>
>  from browser import TabbedView
> +from browser import Browser
>  from webtoolbar import PrimaryToolbar
>  from edittoolbar import EditToolbar
>  from viewtoolbar import ViewToolbar
> @@ -194,6 +195,7 @@ class WebActivity(activity.Activity):
>
>         self._primary_toolbar = PrimaryToolbar(self._tabbed_view, self)
>         self._primary_toolbar.connect('add-link', self._link_add_button_cb)
> +        self._primary_toolbar.connect('add-tab', self._new_tab_cb)
>
>         self._tray = HTray()
>         self.set_tray(self._tray, gtk.POS_BOTTOM)
> @@ -258,6 +260,9 @@ class WebActivity(activity.Activity):
>         else:
>             _logger.debug('Created activity')
>
> +    def _new_tab_cb(self, gobject):
> +        self._load_homepage(new_tab=True)
> +
>     def _shared_cb(self, activity_):
>         _logger.debug('My activity was shared')
>         self.initiating = True
> @@ -354,8 +359,14 @@ class WebActivity(activity.Activity):
>             self.messenger = Messenger(self.tube_conn, self.initiating,
>                                        self.model)
>
> -    def _load_homepage(self):
> -        browser = self._tabbed_view.current_browser
> +    def _load_homepage(self, new_tab=False):
> +        # If new_tab is True, open the homepage in a new tab.
> +        if new_tab:
> +            browser = Browser()
> +            self._tabbed_view._append_tab(browser)
> +        else:
> +            browser = self._tabbed_view.current_browser
> +
>         if os.path.isfile(_LIBRARY_PATH):
>             browser.load_uri('file://' + _LIBRARY_PATH)
>         else:
> @@ -451,6 +462,8 @@ class WebActivity(activity.Activity):
>             elif key_name == 'r':
>                 flags = components.interfaces.nsIWebNavigation.LOAD_FLAGS_NONE
>                 browser.web_navigation.reload(flags)
> +            elif gtk.gdk.keyval_name(event.keyval) == "t":
> +                self._load_homepage(new_tab=True)
>             else:
>                 return False
>
> diff --git a/webtoolbar.py b/webtoolbar.py
> index e7c20be..1f718d5 100644
> --- a/webtoolbar.py
> +++ b/webtoolbar.py
> @@ -35,10 +35,8 @@ from sugar.activity import activity
>  import filepicker
>  import places
>
> -
>  _MAX_HISTORY_ENTRIES = 15
>
> -
>  class WebEntry(AddressEntry):
>     _COL_ADDRESS = 0
>     _COL_TITLE = 1
> @@ -68,7 +66,7 @@ class WebEntry(AddressEntry):
>            recognize changes caused directly by user actions"""
>         self.handler_block(self._change_hid)
>         try:
> -            self.props.text = text
> +            self.props.text = text
>         finally:
>             self.handler_unblock(self._change_hid)
>         self.set_position(-1)
> @@ -177,7 +175,7 @@ class WebEntry(AddressEntry):
>             if selected is None:
>                 selection.select_iter(model[-1].iter)
>                 self._set_text(model[-1][0])
> -            else:
> +            else:
>                 index = model.get_path(selected)[0]
>                 if index > 0:
>                     selection.select_path(index - 1)
> @@ -186,10 +184,10 @@ class WebEntry(AddressEntry):
>         elif keyname == 'Down':
>             if selected is None:
>                 down_iter = model.get_iter_first()
> -            else:
> +            else:
>                 down_iter = model.iter_next(selected)
>             if down_iter:
> -                selection.select_iter(down_iter)
> +                selection.select_iter(down_iter)
>                 self._set_text(model.get(down_iter, 0)[0])
>             return True
>         elif keyname == 'Return':
> @@ -218,13 +216,15 @@ class WebEntry(AddressEntry

Re: [Sugar-devel] [Testing request] Browse-webkit

[Lucian Branescu]

Here's an .xo http://people.sugarlabs.org/lucian/Browse-115.xo

It's not a release (has the same version as last browse) because it's
not yet finished, and most importantly is still segfaults on fedora
(pywebkitgtk's fault probably).

On 22 July 2010 13:42, Sebastian Dziallas  wrote:
> On Tue, Jul 20, 2010 at 3:36 PM, Bernie Innocenti  wrote:
>> El Tue, 20-07-2010 a las 03:07 +0100, Lucian Branescu escribió:
>>> rgs and myself have ported Browse to pywebkitgtk with all features and
>>> we could use some testing.
>>>
>>> You can get it from here
>>> http://git.sugarlabs.org/projects/browse/repos/mainline/trees/webkit
>>> It requires pywebkitgtk 1.1.6 and webkitgtk 1.2.*.
>>
>> Can you provide an installable xo bundle?
>
> Yup, I'd be interested in a release, too. :)
>
> Can you upload one to people.sl.o?
>
> Awesome work!
> --Sebastian
>
>>> Also, note that pywebkitgtk 1.1.6 in fedora (11 and 12 have been
>>> observed so far) segfaults. So either wait for the fix or use another
>>> distro in a VM.
>>
>> I've just pushed an updated pywebkitgtk-1.1.7 rpm to the f11-0.88
>> repository.
>>
>> --
>>   // Bernie Innocenti - http://codewiz.org/
>>  \X/  Sugar Labs       - http://sugarlabs.org/
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Read/evince quick follow up

[Lucian Branescu]

I've enabled epub view. It requires both python-lxml and
python-BeautifulSoup installed (for some reason) and none of the
toolbars work in epub view.

On 20 July 2010 16:51, Lucian Branescu  wrote:
> Another feature that doesn't work is Table of Contents for pdfs that have it.
>
> On 20 July 2010 15:00, Lucian Branescu  wrote:
>> I've implemented copy and search. There may still be some loose ends
>> somewhere and I haven't tested epubs at all.
>>
>> On 20 July 2010 05:24, Gary C Martin  wrote:
>>> Hi Lucian,
>>>
>>> Fab thanks. A git clone of your 
>>> http://git.sugarlabs.org/git/read/evince-2-30.git now does the trick for 
>>> testing in SoaS Mirabelle. Toolbars look good this time :-) I've only 
>>> tested it on a couple of Gutenberg text PDFs so far, so yes as you 
>>> mentioned the Edit toolbar is not so functional yet (no copy, no search). 
>>> Everything else seems great so far e.g.
>>>
>>> - creating bookmarks work
>>> - page count and current page is correct
>>> - forward/back work moving one screens worth at a time (sub menus for by 
>>> page and bookmarks also work)
>>> - view zoom in/out is good
>>> - view zoom to fit width is good
>>> - incremental zoom widget good
>>> - full screen view (and back again) good
>>>
>>> I'll try a wider range of test PDF's later (with more image content, some 
>>> really great edu material at http://www.ck12.org if perhaps at our upper 
>>> target age range).
>>>
>>> Are there any other document types that evince was supporting that I should 
>>> go test?
>>>
>>> Fantastic work!!
>>>
>>> Regards,
>>> --Gary
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Read/evince quick follow up

[Lucian Branescu]

Another feature that doesn't work is Table of Contents for pdfs that have it.

On 20 July 2010 15:00, Lucian Branescu  wrote:
> I've implemented copy and search. There may still be some loose ends
> somewhere and I haven't tested epubs at all.
>
> On 20 July 2010 05:24, Gary C Martin  wrote:
>> Hi Lucian,
>>
>> Fab thanks. A git clone of your 
>> http://git.sugarlabs.org/git/read/evince-2-30.git now does the trick for 
>> testing in SoaS Mirabelle. Toolbars look good this time :-) I've only tested 
>> it on a couple of Gutenberg text PDFs so far, so yes as you mentioned the 
>> Edit toolbar is not so functional yet (no copy, no search). Everything else 
>> seems great so far e.g.
>>
>> - creating bookmarks work
>> - page count and current page is correct
>> - forward/back work moving one screens worth at a time (sub menus for by 
>> page and bookmarks also work)
>> - view zoom in/out is good
>> - view zoom to fit width is good
>> - incremental zoom widget good
>> - full screen view (and back again) good
>>
>> I'll try a wider range of test PDF's later (with more image content, some 
>> really great edu material at http://www.ck12.org if perhaps at our upper 
>> target age range).
>>
>> Are there any other document types that evince was supporting that I should 
>> go test?
>>
>> Fantastic work!!
>>
>> Regards,
>> --Gary
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Read/evince quick follow up

[Lucian Branescu]

I've implemented copy and search. There may still be some loose ends
somewhere and I haven't tested epubs at all.

On 20 July 2010 05:24, Gary C Martin  wrote:
> Hi Lucian,
>
> Fab thanks. A git clone of your 
> http://git.sugarlabs.org/git/read/evince-2-30.git now does the trick for 
> testing in SoaS Mirabelle. Toolbars look good this time :-) I've only tested 
> it on a couple of Gutenberg text PDFs so far, so yes as you mentioned the 
> Edit toolbar is not so functional yet (no copy, no search). Everything else 
> seems great so far e.g.
>
> - creating bookmarks work
> - page count and current page is correct
> - forward/back work moving one screens worth at a time (sub menus for by page 
> and bookmarks also work)
> - view zoom in/out is good
> - view zoom to fit width is good
> - incremental zoom widget good
> - full screen view (and back again) good
>
> I'll try a wider range of test PDF's later (with more image content, some 
> really great edu material at http://www.ck12.org if perhaps at our upper 
> target age range).
>
> Are there any other document types that evince was supporting that I should 
> go test?
>
> Fantastic work!!
>
> Regards,
> --Gary
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [Testing request] Browse-webkit

[Lucian Branescu]

rgs and myself have ported Browse to pywebkitgtk with all features and
we could use some testing.

You can get it from here
http://git.sugarlabs.org/projects/browse/repos/mainline/trees/webkit
It requires pywebkitgtk 1.1.6 and webkitgtk 1.2.*.

Also, note that pywebkitgtk 1.1.6 in fedora (11 and 12 have been
observed so far) segfaults. So either wait for the fix or use another
distro in a VM.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Browse] PDFs inline

[Lucian Branescu]

On 18 July 2010 18:54, Sayamindu Dasgupta  wrote:
> On Sun, Jul 18, 2010 at 9:36 AM, Lucian Branescu
>  wrote:
>> I've seen your merge request on
>> http://git.sugarlabs.org/projects/browse/repos/inline-pdf.
>>
>> Since I've been working on Browse-webkit, I'd like to implement inline
>> PDFs for it as well. However, evince maintainers are very hostile to
>> browser plugins, NPAPI or otherwise
>> (https://bugzilla.gnome.org/show_bug.cgi?id=168933).
>>
>
> I used mozplugger to do this.
>
>> I'd like your advice on how to handle this feature within
>> Browse-webkit. pywebkitgtk has the capability to embed widgets just
>> like you'd embed NPAPI plugins. Should I embed evince or work with
>> poppler directly?
>>
>
> It may be a good idea - but it may be even better to have a simple PDF
> viewer widget (which incorporates an "add to journal" button) using
> the evince-python bindings.
That's what I meant, I'll make a widget with a small toolbar which
embeds evince (libevview).

I do seem to have a problem with evince 2.30, they seem to have broken
their API. http://library.gnome.org/devel/libevview/2.30/
>
> Thanks,
> Sayamindu
>
>
> --
> Sayamindu Dasgupta
> [http://sayamindu.randomink.org/ramblings]
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [Browse] PDFs inline

[Lucian Branescu]

I've seen your merge request on
http://git.sugarlabs.org/projects/browse/repos/inline-pdf.

Since I've been working on Browse-webkit, I'd like to implement inline
PDFs for it as well. However, evince maintainers are very hostile to
browser plugins, NPAPI or otherwise
(https://bugzilla.gnome.org/show_bug.cgi?id=168933).

I'd like your advice on how to handle this feature within
Browse-webkit. pywebkitgtk has the capability to embed widgets just
like you'd embed NPAPI plugins. Should I embed evince or work with
poppler directly?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse owner

[Lucian Branescu]

Silbe and I are Browse maintainers now. So if erikos is ok with it,
you can pass ownership to either one of us.

On 18 July 2010 11:12, Bernie Innocenti  wrote:
> Hello erikos,
>
> you're still marked the owner of the Browse project on
> git.sugarlabs.org.
>
> If you don't mind, I'll pass ownership of the project and mainline to
> Lucian (or Raul). You will still be able to commit to mainline.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Design Team meeting (was: Re: UI experiments: pop-up menus and hot corners)

[Lucian Branescu]

I'd like to add to that list:
- Saving web pages from browse/SSBs

If there's time, I'd like some designers' opinion on how it should look.

On 8 July 2010 11:49, Sascha Silbe  wrote:
> Excerpts from Gary Martin's message of Thu Jul 08 09:13:23 + 2010:
>
>> > It would be great to hold Design Team meetings regularly (bi-weekly or at 
>> > least monthly). We have already queued up a lot to talk about again.
>>
>> Do you have specific items we can try to cover on the mail-list first? Real 
>> time design meetings are tough to schedule and (in my opinion) are usually 
>> better focused on trying to move forward a goal or two.
>
> These are the topics / open issues I've collected from the mailing
> list and the bug tracker (see wiki page [1] for links to patches):
>
> - Journal backup UI (Patch from Martin Abente, Patch from Sascha Silbe)
> - Alerts (Patch from Anish Mangal) and notifications
> - Uncaught exception handler (#2063)
> - How to handle start-up delay due to data store migration (#1546)?
> - "Your Journal is empty" shown for unreadable storage media (#1810)
> - invalid/unknown colors are shown as owner colors (#1750)
> - Erasure of downloaded Activity entries in Journal permanently removes
>  the code bundle (#1512)
> - Drop down menus give no indication of their existence, also are too
>  slow to load (#1169, Patch from Michael Stone)
>
> There are also 23 open tickets [2] filed against the design component in
> Trac.
>
> Sascha
>
> [1] http://wiki.sugarlabs.org/go/Design_Team/Meetings
> [2] 
> https://bugs.sugarlabs.org/query?component=design&status=accepted&status=assigned&status=new&status=reopened
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Patches to mail list, or patches to trac?

[Lucian Branescu]

I was thinking that google groups deals great with two views on the
same discussion (forum-like comments and ml). Could something like
that be done for trac? Would it be a good idea?

On 6 July 2010 09:07, Simon Schampijer  wrote:
> On 07/05/2010 02:47 PM, Tomeu Vizoso wrote:
>> On 07/01/2010 08:32 PM, Gary Martin wrote:
>>> Hi folks,
>>>
>>> Just wanted to ask the obvious question. Patches to mail list, or
>>> patches to trac?
>>
>> About acceptance, the current process is in place until its wiki page is
>> changed:
>>
>> http://wiki.sugarlabs.org/go/Development_Team/Code_Review
>>
>> Now, that process already mentioned reviews on mailing lists in some
>> cases and of course, doesn't forbid people from sending patches to the
>> ml for non-acceptance reviews.
>>
>>> Patches to mail-list seem great for quick random 'easy' feedback from
>>> and for any one who cares to give it, and I really like seeing little
>>> code snippets go past. However it seems vital that with the current
>>> process we at least make a final closing stage (currently tickets in
>>> trac) where the hard final call can be made and the loop closed.
>>
>> Yup, I guess this is the acceptance part of it which needs to be very
>> clear to submitters and thus should be agreed by all maintainers of
>> official modules.
>>
>>> Personally I read mail in a bunch of different places/devices and
>>> there's no way I can currently (and sanely) keep track of all the
>>> list activity and know who suggested what, what was actually agreed,
>>> and what is still outstanding. I've had a few patches and reviews now
>>> from kind folk posting to the mail-list, but for me, I've ended up
>>> having to ask folks to create git clones so I can pull in patches in
>>> a maintainable work flow.
>>>
>>> I dread to think what it must be like trying to look after several
>>> large core modules!
>>
>> Last we discussed this, I understood that the conclusion is that the
>> parties interested in a particular submission will keep pinging the
>> maintainer in public (irc, ml) until it gets reviewed.
>>
>> I still think it would be much better to have a simpler queue such as
>> http://bugs.sugarlabs.org/wiki/TomeuReviewQueue in which you know more
>> clearly what is awaiting review and exactly which patches they are
>> (well, when the submitter properly discards all patches and don't put
>> several patches in the same ticket), but it was contended that the
>> "bureaucracy" needed was too much  and discouraged contributions.
>>
>> Regards,
>>
>> Tomeu
>
> The main problem I am seeing with having trac and the mailing list being
> used is that the two parts get out of sync. As a "well-behaving"
> maintainer, I have to follow both discussions in order to follow up.
>
> For example take http://bugs.sugarlabs.org/ticket/1926  There is a
> ticket and a mailing list discussion with patches, icons etc. Now, there
> is no link in the ticket to this discussion, and one needs to follow
> both tracks. Of course adding policies such as "link the ml-discussion
> in the ticket" can help here.
>
> Do people have a plan/policy for this?
>
> Regards,
>    Simon
>
>
>
>
>
>
>
>
>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Browse: Add support for creating multiple tabs

[Lucian Branescu]

I'm not sure it's a good idea to merge this if it causes Browse (vital
app) to occasionally crash on SoaS (very popular Sugar environment).
At the very least, the tabs feature should be disabled if that certain
version of cairo is detected.

Also, it would be more convenient if you put your work in a fork of
Browse at http://git.sugarlabs.org/projects/browse

On 29 June 2010 22:19, Anish Mangal  wrote:
>> 1. On f13 based sugar environments (such as soas3, jhbuild-0.88), this
>
> Oops, I meant soas3 and jhbuild-0.88 running on f13.
>
> On Wed, Jun 30, 2010 at 2:46 AM, Anish Mangal  
> wrote:
>> Note:
>>
>> 1. On f13 based sugar environments (such as soas3, jhbuild-0.88), this
>> patch will occasionally cause Browse to crash when closing tabs. This
>> probably happens because of a bug [1] (or something very similar to
>> this). As a workaround, one can downgrade the cairo package from
>> cairo-1.8.10 to cairo-1.8.8-1.fc11 (or upgrade to the latest
>> development version 1.9.10-1, though I haven't tested that).
>>
>> 2. This patch doesn't add an entry 'open link in new tab' to the
>> context menu. That can
> come as a separate patch.
>>
>>
>> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551852
>>
>> --
>> Anish Mangal
>> an...@sugarlabs.org
>>
>>
>> On Wed, Jun 30, 2010 at 2:28 AM, anishmangal2002
>>  wrote:
>>> This patch adds support to create multiple tabbed windows
>>> in Browse. A tab may be added by either clicking the add tab
>>> ('+') icon in the activity toolbar or by pressing 'ctrl+t'.
>>>
>>> Signed-off-by: anishmangal2002 
>>> ---
>>>  icons/add-tab.svg |   86 
>>> +
>>>  webactivity.py    |   11 +++
>>>  webtoolbar.py     |   21 +
>>>  3 files changed, 118 insertions(+), 0 deletions(-)
>>>  create mode 100644 icons/add-tab.svg
>>>
>>> diff --git a/icons/add-tab.svg b/icons/add-tab.svg
>>> new file mode 100644
>>> index 000..0220993
>>> --- /dev/null
>>> +++ b/icons/add-tab.svg
>>> @@ -0,0 +1,86 @@
>>> +
>>> +
>>> +
>>> +>> +   xmlns:dc="http://purl.org/dc/elements/1.1/";
>>> +   xmlns:cc="http://creativecommons.org/ns#";
>>> +   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
>>> +   xmlns:svg="http://www.w3.org/2000/svg";
>>> +   xmlns="http://www.w3.org/2000/svg";
>>> +   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd";
>>> +   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape";
>>> +   version="1.1"
>>> +   width="55"
>>> +   height="55"
>>> +   id="svg2"
>>> +   inkscape:version="0.47 r22583"
>>> +   sodipodi:docname="add-tab.svg">
>>> +  >> +     id="metadata10">
>>> +    
>>> +      >> +         rdf:about="">
>>> +        image/svg+xml
>>> +        >> +           rdf:resource="http://purl.org/dc/dcmitype/StillImage"; />
>>> +      
>>> +    
>>> +  
>>> +  >> +     pagecolor="#ff"
>>> +     bordercolor="#66"
>>> +     borderopacity="1"
>>> +     objecttolerance="10"
>>> +     gridtolerance="10"
>>> +     guidetolerance="10"
>>> +     inkscape:pageopacity="0"
>>> +     inkscape:pageshadow="2"
>>> +     inkscape:window-width="1280"
>>> +     inkscape:window-height="721"
>>> +     id="namedview8"
>>> +     showgrid="false"
>>> +     inkscape:zoom="4.2909091"
>>> +     inkscape:cx="27.5"
>>> +     inkscape:cy="27.033898"
>>> +     inkscape:window-x="0"
>>> +     inkscape:window-y="27"
>>> +     inkscape:window-maximized="1"
>>> +     inkscape:current-layer="layer1" />
>>> +  >> +     id="defs4">
>>> +    >> +       sodipodi:type="inkscape:persp3d"
>>> +       inkscape:vp_x="0 : 27.5 : 1"
>>> +       inkscape:vp_y="0 : 1000 : 0"
>>> +       inkscape:vp_z="55 : 27.5 : 1"
>>> +       inkscape:persp3d-origin="27.5 : 18.33 : 1"
>>> +       id="perspective12" />
>>> +  
>>> +  >> +     transform="translate(0,-997.36218)"
>>> +     id="layer1">
>>> +    >> +       width="55"
>>> +       height="55"
>>> +       x="0"
>>> +       y="0"
>>> +       transform="translate(0,997.36218)"
>>> +       id="rect2818"
>>> +       style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:none" />
>>> +    >> +       width="9"
>>> +       height="38"
>>> +       x="23"
>>> +       y="1005.8622"
>>> +       id="rect3599"
>>> +       style="fill:#ff;fill-opacity:1;stroke:none" />
>>> +    >> +       width="8.94349"
>>> +       height="37.99044"
>>> +       x="1020.3485"
>>> +       y="-47.595592"
>>> +       
>>> transform="matrix(-0.00107369,0.9942,-0.9889,-0.00148761,0,0)"
>>> +       id="rect3599-4"
>>> +       style="fill:#ff;fill-opacity:1;stroke:none" />
>>> +  
>>> +
>>> diff --git a/webactivity.py b/webactivity.py
>>> index 4be551e..5f4f917 100644
>>> --- a/webactivity.py
>>> +++ b/webactivity.py
>>> @@ -152,6 +152,7 @@ def _set_accept_languages():
>>>     logging.debug('LANG set')
>>>
>>>  from browser import TabbedView
>>> +from browser import Browser
>>>  from webtoolbar import PrimaryToolbar
>>>  from edittoolbar import EditToolbar
>>>  from viewtoolbar import Vi

Re: [Sugar-devel] [RFC] Better disk format for journal entries

[Lucian Branescu]

I think it would be very useful if the datastore were less opaque to
regular tools. Especially as a developer, I find the Journal sometimes
gets in the way and going around it should be easier.

Related to the Gnome thread, this sort of work might help in making
Sugar impervious to Gnome damage, or even go towards integrating the
Sugar datastore into Gnome's future equivalent of the Journal.

On 27 June 2010 04:06, Michael Stone  wrote:
> Folks,
>
> I've longed, for quite some time, for an encoding of Sugar's journal entries
> that is more amenable to manipulation with standard Linux tools and APIs. I've
> also longed for a format that is friendly to rainbow and which can encode both
> the data necessary for today's journal as well as the data necessary for 
> Eben's
> Journal redesign mockups.
>
> A few days ago, I wrote a little bit about what I think such a format might
> look like over here:
>
>   http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024908.html
>
> Unfortunately, this note didn't generate much of a response -- thus, to whet
> your appetite further, here's a (rough!) exporter from today's DS into the
> format sketched in that note, available both in the the patch following this
> note and in my combined sugar git repo [1] in the "xos" branch.
>
> Already, I find it helpful both for browsing my DS with filesystem tools and
> for resuming activities from the Terminal.
>
> What cool things can you think of to do with it?
>
> Regards,
>
> Michael
>
> [1]: Links to my sugar git repo:
>
>    http://dev.laptop.org/git/users/mstone/sugar/commit/?h=xos
>    http://dev.laptop.org/git/users/mstone/sugar/snapshot/sugar-xos.tar.gz
>    git://dev.laptop.org/users/mstone/sugar
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] MP3 to ogg converter

[Lucian Branescu]

Keep in mind that mp3 already is a lossy codec. If you convert from
mp3 to ogg, you'll be losing a lot of quality. Usually you should only
convert from a lossless coded (like flac) to a lossy one (mp3/ogg).

I think you can try mencoder to encode between mp3 and ogg.

On 26 June 2010 09:28, javed khan  wrote:
> Hi all
> i have some mp3 files which i need to convert to ogg.
> i tried mp32ogg but it didn't work.
> i have xo 1.5 with
> build = 210 customized os
> sugar 0.84.2
> firmware q333
> browse = 108
>
> Regards
>
> --
> Javid Alam
> Software Developer and Technical support Officer OLPC
> Ministry of Education
> Kabul Afghanistan
> contact: +93(0)798123451
> alternative email: javid.a...@moe.gov.af
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] JavaScript on OLPC

[Lucian Branescu]

Newer versions of Browse have support for tabs, but there is no UI
element to create more tabs. However, windows created from JavaScript
will appear as tabs.

Not sure about alert, you might just have a really old Browse. What
version is it?

On 25 June 2010 19:32, Dan Healy  wrote:
> I have a browser based application that works, sorta, on OLPC.  I find I
> cannot have more than one browser page open at a time.  I cannot open a
> second window and have two windows available at the same time.  Is that
> correct or am I missing something?
>
> Also, in that same vein, the JavaScript alert function will not work.  When
> I click a button that creates an alert on standard Firefox, nothing
> happens.  Any ideas on how I can get around these problems?
>
> Thanks,
>
> Dan H.
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] A Tale of Sugar and Pippy

[Lucian Branescu]

I think all activities should have "Report bug" on the toolbar
somewhere. And of course a system in place on the other end, perhaps
email-to-trac?

On 22 June 2010 14:25, Martin Dengler  wrote:
> On Tue, Jun 22, 2010 at 06:07:50PM +1000, James Cameron wrote:
>> On Tue, Jun 22, 2010 at 03:39:46AM -0400, Michael Stone wrote:
>> > Here, we reach the end of my tale. You see, my friend and I agreed
>> > that our desired next step would be to send our change to sugar-devel@
>> > along with, well, this story.
>> >
>> >    -1: Unfortunately, there's no obvious way to do this with Sugar and
>> >        Pippy today.
>> >
>> > Anyone have thoughts on what "stepping stones" Sugar and Pippy ought
>> > to provide to make this act of reflection and sharing feel as natural
>> > as the act of starting Pippy or of making the change that we want to
>> > describe and to share?
>>
>> We might not be able to depend on an e-mail path.  So I envisage a
>> small web application on sugarlabs.org
>
> Both an email and a POST request could be tried - saving the entry to
> the journal might be good, which then opens up a whole other set of
> routes (and confusions) for submission/sharing (and its resultant UI
> challenges).
>
> To bikeshed a bit, perhaps "share via email" and/or "share via web"
> could become part of Activities' sharing options.
>
> Martin
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] depending on introspection

[Lucian Branescu]

The way I see it, activities can't really use PyGI until it's a sugar
dependency. The sooner it is available as a dependency on all relevant
platforms (debian being one of them), the sooner important things like
Browse can start using it.

So, how about making some packages for all relevant platforms? There
can be some PPAs for ubuntu and some repos for debian and whatever
other platforms we care about. This will be some work, but I'm sure
other projects are interested in this as well.

On 18 June 2010 18:59, Daniel Drake  wrote:
> On 18 June 2010 12:20, Sascha Silbe 
>> No, they're my problem because I develop Sugar on Debian systems. Can you 
>> afford to leave me behind? Is it worth the advantage of being able to use 
>> introspection (or whatever other bleeding edge technology that requires 
>> modifying major system libraries instead of just installing additional ones) 
>> right now?
>
> Regardless of who or which, I don't think its right that the problems
> of a single developer or distribution should hold back the rest of the
> Sugar project, which is realistically much much larger than that.
>
> Daniel
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Sugar-Devel] Sugar Web Engine

[Lucian Branescu]

After much trouble getting hulahop & xpcom to work in the abstraction
layer webwrap, I've decided to drop it and focus on pywebkitgtk. To
this end, yesterday I got Browse to start and load pages with
pywebkitgtk, but with several features disabled. I'll be working on
getting all of Browse's features to work with pywebkitgtk.

I've also looked at webkitgtk+'s API and I'm confident that switching
to PyGI will be quite easy, mostly just renaming things.

On 16 June 2010 11:48, Lucian Branescu  wrote:
> Unfortunately, that doesn't solve any of my problems.
>
> I would gladly drop hulahop entirely (it's a mess and very low-level), but
> several people have expressed concern that gecko might be a better choice
> long-term. However, I have not been able to confirm any of their performance
> concerns. In my tests, gecko always used more memory and was much slower
> than webkit. Also, xulrunner is made first for firefox and second for
> embedding, and it shows painfully.
>
> On the other hand, I can't decide by myself to use PyGI since it's too
> experimental for a platform's main browser and the rest of Sugar doesn't use
> it. However, the API of pywebkitgtk would be similar to webkitgtk+PyGI, so
> switching later on shouldn't be very hard. Especially since pywebkitgtk's
> author himself already did it.
>
> Because of various hulahop & xpcom quirks, webwrap (the abstraction layer)
> is proving increasingly hard to write. I will give it a few more days, but
> if I can't figure out a clean way to wrab both hulahop and pywebkitgtk I'll
> drop hulahop entirely and let any future switching back to hulahop rely on
> git.
>
> On 16 Jun 2010 11:07, "Tomeu Vizoso"  wrote:
>
> On Sun, Jun 6, 2010 at 15:33, Lucian Branescu 
> wrote:
>> I've received eve...
>
> Just wanted to make sure you know that the pywebkitgtk+ maintainer
> recommends using PyGI instead:
>
> http://janalonzo.wordpress.com/2010/01/18/using-introspected-webkitgtk-in-gwibber/
>
> That was written in January and since then PyGI has progressed greatly.
>
> I personally think that you should have less concerns than other
> people that are moving to PyGI right now.
>
> As a general remark, I don't think it's a good idea to cling to
> software modules whose authors are so willing to drop down and will be
> less painful in the medium term if people start moving now.
>
> That said, it hasn't been decided yet that Sugar will depend on PyGI
> from 0.90 on (see a new thread from today).
>
> Regards,
>
> Tomeu
>
>> Since it's already late into the project, unless someone has a better
>> idea, I'll stick to fully...
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] depending on introspection

[Lucian Branescu]

+1

PyGI as a working dependency would make Browse work somewhat easier
and would assure Browse's future.

On 16 June 2010 10:27, Tomeu Vizoso  wrote:
> Hi,
>
> anybody has thoughts about the convenience (or not) of making Sugar
> depend on the introspection stack in GNOME 3.0?
>
> The biggest practical downside will be that Sugar 0.90 will only run
> on next-cycle distros (Fedora 14, Ubuntu Maverick, etc) unless people
> backport a lot of other packages (not recommended nor likely).
>
> The upsides include: gradually dropping static bindings which are
> generally unmaintained, less memory use, less cpu usage during
> startup, access to new APIs such as GSettings and Telepathy-GLib.
>
> Thanks,
>
> Tomeu
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Sugar-Devel] Sugar Web Engine

[Lucian Branescu]

Unfortunately, that doesn't solve any of my problems.

I would gladly drop hulahop entirely (it's a mess and very low-level), but
several people have expressed concern that gecko might be a better choice
long-term. However, I have not been able to confirm any of their performance
concerns. In my tests, gecko always used more memory and was much slower
than webkit. Also, xulrunner is made first for firefox and second for
embedding, and it shows painfully.

On the other hand, I can't decide by myself to use PyGI since it's too
experimental for a platform's main browser and the rest of Sugar doesn't use
it. However, the API of pywebkitgtk would be similar to webkitgtk+PyGI, so
switching later on shouldn't be very hard. Especially since pywebkitgtk's
author himself already did it.

Because of various hulahop & xpcom quirks, webwrap (the abstraction layer)
is proving increasingly hard to write. I will give it a few more days, but
if I can't figure out a clean way to wrab both hulahop and pywebkitgtk I'll
drop hulahop entirely and let any future switching back to hulahop rely on
git.

On 16 Jun 2010 11:07, "Tomeu Vizoso"  wrote:

On Sun, Jun 6, 2010 at 15:33, Lucian Branescu 
wrote:
> I've received eve...
Just wanted to make sure you know that the pywebkitgtk+ maintainer
recommends using PyGI instead:

http://janalonzo.wordpress.com/2010/01/18/using-introspected-webkitgtk-in-gwibber/

That was written in January and since then PyGI has progressed greatly.

I personally think that you should have less concerns than other
people that are moving to PyGI right now.

As a general remark, I don't think it's a good idea to cling to
software modules whose authors are so willing to drop down and will be
less painful in the medium term if people start moving now.

That said, it hasn't been decided yet that Sugar will depend on PyGI
from 0.90 on (see a new thread from today).

Regards,

Tomeu


> Since it's already late into the project, unless someone has a better
> idea, I'll stick to fully...
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[Lucian Branescu]

Afaik, hulahop's WebView has a method do_setup, which is a convention
b the initial hulahop devs for a method to be called after the page
has loaded.

On 10 June 2010 13:36, Bernie Innocenti  wrote:
> El Wed, 09-06-2010 a las 23:46 -0300, Gonzalo Odiard escribió:
>> SocialCalc depends of hulahop.
>> My activity Elements too.
>
> Ugh. BTW, SocialCalc hardcodes a 3-second delay for localization which
> opens a race condition. It works intermittently on the XO-1 with Sugar
> 0.84 and it probably fails to work altogether in other scenarios.
>
> Does anyone have any idea how it could be done in an event-driven way?
> I'm afraid I know nothing about XPCOM embedding.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[Lucian Branescu]

On 10 June 2010 04:28, Jameson Quinn  wrote:
>
>
> 2010/6/9 Luke Faraone 
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 06/09/2010 08:11 PM, Bernie Innocenti wrote:
>> > As far as I know, Browse is still the only hulahop user on this planet,
>> > so it's not like we need to keep it around for API compatibility.
>>
>> Actually, hulahop is used by pyjamas[1], as evidenced by these bug
>> reports[2][3] spawned when sugar-hulahop was removed from Ubuntu Lucid.
>> An aside, according to upstream this is not an integral part of their
>> project, but it might be a good idea to involve them in the discussion.
>
> These days, I do my work in pyjamas - on the cloud. I have never used
> pyjamas on the desktop, but for people who do, hulahoop* was the least
> painful way to get there, and its removal sparked indignation.
>
> *OK, it's called hulahop, but this way all the code names mesh more
> surreally.

Sir, you made my day.

>
> Seriously, though: the fact that pyjamas-desktop can exist without hulahop
> doesn't make it attractive to lose it. It may not be integral, but I don't
> see anybody in the pyjamas world who would be replacing it any time soon, so
> it is essential as a practical matter.
>
> Jameson
>

For pyjamas's purposes, i'm not sure if webwrap (my abstraction layer
over hulahop and pywebkitgtk) would be enough. But if I do this right,
all Sugar apps will be able to use either hulahop or pywebkitgtk
without any further effort.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[Lucian Branescu]

Folding hulahop into this abstraction layer could possibly make sense.
Let me finish it first, though. Hulahop has a lot of weird code and a
lot of XPCOM magic.

Both pywebkitgtk and hulahop have very similar WebView classes. My
wrapper now offers some extra methods for engine-specific bits and a
few utility functions, but very little is added to the base WebView
classes.

On 10 June 2010 01:11, Bernie Innocenti  wrote:
> El Wed, 09-06-2010 a las 13:30 +0100, Lucian Branescu escribió:
>
>> After some debate on what exactly I should be doing, I've decided that
>> it's both prudent and relatively easy to make that abstraction layer
>> after all. Since I last used it, pywebkitgtk's API has grown much
>> closer to hulahop's, so a snippet similar to this one
>> http://wiki.laptop.org/go/Sugar_Code_Snippets#WebView already works
>> for both hulahop and pywebkitgtk.
>
> To simplify our dependencies, couldn't you also fold hulahop into
> WebView, or vice-versa?
>
> As far as I know, Browse is still the only hulahop user on this planet,
> so it's not like we need to keep it around for API compatibility.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[Lucian Branescu]

On 8 June 2010 05:54, Michael Stone  wrote:
> Hi folks,
>
> Under the temporary working hypothesis that we want to make a Sugar release in
> a couple of months, I'd like to know more about what we might find ourselves
> integrating. Here's my current list of, er... mostly unvetted rumors. :)
>
>   1.  Aleksey: 0install integration, Vala-based sugar-toolkit
>   2.  Sascha: versioned datastore
>   3.  Tomeu: collaboration refactoring
>   4.  Gary + Christian: alternative activity launch UI
>   5.  Michael: git repo reorganization and build system rewrite
>   6.  Gary + Scott: preliminary touch-related UI tweaks
>   7.  Raul: rainbow
>   8.  Esteban: virtual keyboard
>   9.  Lucian: browser abstraction
After some debate on what exactly I should be doing, I've decided that
it's both prudent and relatively easy to make that abstraction layer
after all. Since I last used it, pywebkitgtk's API has grown much
closer to hulahop's, so a snippet similar to this one
http://wiki.laptop.org/go/Sugar_Code_Snippets#WebView already works
for both hulahop and pywebkitgtk.

I will be going forward trying to remove all hulahop & xpcom imports
from Browse, effectively writing a complete hulahop backend for my
abstraction layer. After that, I'll implement the pywebkitgtk backend.
>   10. Martin L.: polish
>   11. Walter: write to journal any time
>   12. Simon: dotted activity versions
>   13. Walter: enhanced color selector
>   14. Jorge + Martin A.: journal backup + restore
>   15. Andres: journal entry sorting
>   15. : 
>
> Comments? Additions? Substitutions? Deletions?
>
> Michael
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] ANNOUNCE: Sugar 0.88 for the XO-1

[Lucian Branescu]

I'm not sure what this is and I don't really have the time to look into it atm.

Browse is in a difficult situation because hulahop, pywebkitgtk and
webkitgtk+PyGI all have hazy futures. Over the summer I'll try and get
Browse in a better situation (the plan so far is a thin abstraction
layer).

So many more bugs will crop up and some others will vanish. Not sure
about maintenance after GSoC though, I have both uni and work, so
little free time.

On 8 June 2010 16:07, Bernie Innocenti  wrote:
> El Tue, 08-06-2010 a las 13:21 +1000, fors...@ozonline.com.au escribió:
>> OS 240py XO-1
>>
>> Though I cannot see any way to create tabs in browse, sometimes clicking 
>> links in frames creates tabs which behave erratically eg zero width tab
>>
>> http://wiki.sugarlabs.org/images/e/ec/Screenshot_of_Browse_0s240py_.png
>
>
> Simon, Lucian,
>
> any idea what may be causing this?
>
> More importantly, is Browse really unmaintained at this time?
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Sugar-Devel] Sugar Web Engine

[Lucian Branescu]

On 8 June 2010 15:01, Peter Robinson  wrote:
> Hi Luncian,
>
> On Sun, Jun 6, 2010 at 2:33 PM, Lucian Branescu
>  wrote:
>> I've received even less feedback from upstreams about their respective 
>> engines.
>>
>> There are still 2 issues:
>> 1) Mozilla have given up on having xulrunner work as a distro-provided
>> VM and now they just bundle it.. They plan some major changes to
>> embedding and they have no plan forward that would allow hulahop to
>> exist. It's no longer just about maintaining hulahop, but the entire
>> stack up from gecko.
>
> Sorry, the statement above seems inconclusive. Have you actually
> received confirmation from Mozilla that xulrunner is no longer going
> to be supported or is it just assumed due to their silence? Is that
> published somewhere if its official?
I went by what was on the wiki. Considering feedback I did eventually
get from Mozilla, the wiki was exaggerating.
>
> There are a number of both open and closed projects that depend on
> xulrunner so I would be somewhat surprised if they dropped support for
> it. Songbird. TomTom Home, Komodo IDE and OpenKomodo are all based on
> xulrunner. Its also used as part of a number of Mozilla projects.
>
> The other component that hulahop uses that caused us issues during the
> SoaS v3 release time frame was the support of pyxpcom was dropped from
> the main codebase. My understanding for the reason for this was
> actually a request from ActiveState (developers of Komodo/openKomodo)
> who are the maintainers of that code so they could develop and release
> it on a separate timeline to the main xulrunner release. Its still
> supported even if not in certain distros. You might find contacting
> them directly to find out their plans might yield quicker and better
> results.
>
>> 2) pywebkitgtk does not have a clear future. The changelog shows
>> activity, but stable maintenance is not assured
>>
>> 3) webkitgtk+ and PyGI might be the best solution, but it doesn't yet
>> work everywhere. From a technical p.o.v. the bits missing from PyGI
>> should not (significantly) hinder Browse, since web engines tend to
>> have comparatively little interaction with their GUIs.
>>
>> Right now, the only option that would actually works everywhere we
>> care about is pywebkitgtk. While it may not be future-proof, PyGI
>> would be targeting the same webkit API, so switching should be very
>> easy.
>>
>> Since it's already late into the project, unless someone has a better
>> idea, I'll stick to fully porting Browse to pywebkitgtk, using any
>> Surf code that is relevant. This should result in a fully-working
>> Browse with SSB features in time for GSoC that also has a clear enough
>> future.
>
> Sorry for the delayed response. It might be better in the short term
> to stick with hulahop / xulrunner until PyGI gets to a state that its
> usable. Let me know if I can help.
This week I'll try to finish the prototype abstraction layer. If that
works decently, I'll go with that and fully implement hulahop and
pywebkitgtk backends. If not, I'll stick to hulahop, fix whatever bugs
there are and implement SSB features.
>
> Peter
>
>> On 31 May 2010 13:41, Lucian Branescu  wrote:
>>> Since I got little feedback about the time, there will be a meeting in
>>> #sugar-meeting at 3PM GMT
>>>
>>> On 31 May 2010 10:09, Tomeu Vizoso  wrote:
>>>> On Sun, May 30, 2010 at 01:58, Lucian Branescu
>>>>  wrote:
>>>>> In case you don't already know, I'm doing a GSoC project on improving
>>>>> the browser engine situation in Sugar
>>>>> http://wiki.sugarlabs.org/go/Summer_of_Code/2010/AbstractBrowser
>>>>>
>>>>> My exams haven't finished yet (last one on Wednesday), so before I
>>>>> start working, I want the opinion of people that use web engines in
>>>>> sugar applications or that are otherwise interested in web engines for
>>>>> sugar on how to proceed.
>>>>>
>>>>> I'd like answers to questions like "Should I drop hulahop and focus on
>>>>> webkit?" or "Is an API like hulahop's nice?", etc.
>>>>
>>>> What we need to find out in order to find the right answers to that is
>>>> what's the future of xulrunner. If Mozilla plans to drop some part of
>>>> their platform essential for hulahop, or if distros are not willing to
>>>> keep packaging it in a way that hulahop can work, then we should just
>>>> forget about it and move to

Re: [Sugar-devel] [Sugar-Devel] Sugar Web Engine

[Lucian Branescu]

I've received even less feedback from upstreams about their respective engines.

There are still 2 issues:
1) Mozilla have given up on having xulrunner work as a distro-provided
VM and now they just bundle it.. They plan some major changes to
embedding and they have no plan forward that would allow hulahop to
exist. It's no longer just about maintaining hulahop, but the entire
stack up from gecko.

2) pywebkitgtk does not have a clear future. The changelog shows
activity, but stable maintenance is not assured

3) webkitgtk+ and PyGI might be the best solution, but it doesn't yet
work everywhere. From a technical p.o.v. the bits missing from PyGI
should not (significantly) hinder Browse, since web engines tend to
have comparatively little interaction with their GUIs.

Right now, the only option that would actually works everywhere we
care about is pywebkitgtk. While it may not be future-proof, PyGI
would be targeting the same webkit API, so switching should be very
easy.

Since it's already late into the project, unless someone has a better
idea, I'll stick to fully porting Browse to pywebkitgtk, using any
Surf code that is relevant. This should result in a fully-working
Browse with SSB features in time for GSoC that also has a clear enough
future.

On 31 May 2010 13:41, Lucian Branescu  wrote:
> Since I got little feedback about the time, there will be a meeting in
> #sugar-meeting at 3PM GMT
>
> On 31 May 2010 10:09, Tomeu Vizoso  wrote:
>> On Sun, May 30, 2010 at 01:58, Lucian Branescu
>>  wrote:
>>> In case you don't already know, I'm doing a GSoC project on improving
>>> the browser engine situation in Sugar
>>> http://wiki.sugarlabs.org/go/Summer_of_Code/2010/AbstractBrowser
>>>
>>> My exams haven't finished yet (last one on Wednesday), so before I
>>> start working, I want the opinion of people that use web engines in
>>> sugar applications or that are otherwise interested in web engines for
>>> sugar on how to proceed.
>>>
>>> I'd like answers to questions like "Should I drop hulahop and focus on
>>> webkit?" or "Is an API like hulahop's nice?", etc.
>>
>> What we need to find out in order to find the right answers to that is
>> what's the future of xulrunner. If Mozilla plans to drop some part of
>> their platform essential for hulahop, or if distros are not willing to
>> keep packaging it in a way that hulahop can work, then we should just
>> forget about it and move to webkit.
>>
>>> I'd like to set up a meeting on #sugar-meeting on Monday between 9 AM
>>> and 9 PM GMT, depending on the availability of attendees.
>>
>> Great idea!
>>
>> Regards,
>>
>> Tomeu
>>
>>> Individual chats/ml are also welcome, but an IRC meeting would be ideal.
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Striking Activity for XO 1.0 (Peru)

[Lucian Branescu]

Physics is amazing.

On 3 Jun 2010 16:27, "Hernan Pachas"  wrote:

Hello all

I have a consultation, we need a "striking" activity to install in the XO.

 That is striking? That calls the visual attention of the persons who look
at the XO.

 Do you can please, send a list of striking activities to prove them
locally?

---Hernan


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Sugar-Devel] Sugar Web Engine

[Lucian Branescu]

Since I got little feedback about the time, there will be a meeting in
#sugar-meeting at 3PM GMT

On 31 May 2010 10:09, Tomeu Vizoso  wrote:
> On Sun, May 30, 2010 at 01:58, Lucian Branescu
>  wrote:
>> In case you don't already know, I'm doing a GSoC project on improving
>> the browser engine situation in Sugar
>> http://wiki.sugarlabs.org/go/Summer_of_Code/2010/AbstractBrowser
>>
>> My exams haven't finished yet (last one on Wednesday), so before I
>> start working, I want the opinion of people that use web engines in
>> sugar applications or that are otherwise interested in web engines for
>> sugar on how to proceed.
>>
>> I'd like answers to questions like "Should I drop hulahop and focus on
>> webkit?" or "Is an API like hulahop's nice?", etc.
>
> What we need to find out in order to find the right answers to that is
> what's the future of xulrunner. If Mozilla plans to drop some part of
> their platform essential for hulahop, or if distros are not willing to
> keep packaging it in a way that hulahop can work, then we should just
> forget about it and move to webkit.
>
>> I'd like to set up a meeting on #sugar-meeting on Monday between 9 AM
>> and 9 PM GMT, depending on the availability of attendees.
>
> Great idea!
>
> Regards,
>
> Tomeu
>
>> Individual chats/ml are also welcome, but an IRC meeting would be ideal.
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [Sugar-Devel] Sugar Web Engine

[Lucian Branescu]

In case you don't already know, I'm doing a GSoC project on improving
the browser engine situation in Sugar
http://wiki.sugarlabs.org/go/Summer_of_Code/2010/AbstractBrowser

My exams haven't finished yet (last one on Wednesday), so before I
start working, I want the opinion of people that use web engines in
sugar applications or that are otherwise interested in web engines for
sugar on how to proceed.

I'd like answers to questions like "Should I drop hulahop and focus on
webkit?" or "Is an API like hulahop's nice?", etc.

I'd like to set up a meeting on #sugar-meeting on Monday between 9 AM
and 9 PM GMT, depending on the availability of attendees.

Individual chats/ml are also welcome, but an IRC meeting would be ideal.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel