headers
Gary C Martin | 1 Jun 21:29

Re: Browse v86 rainbow issue on update 1-706?

On 29 May 2008, at 03:58, Martin Dengler wrote:

> On Thu, May 29, 2008 at 03:42:55AM +0100, Gary C Martin wrote:
>> On 28 May 2008, at 18:55, Martin Dengler wrote:
>>> Is this rainbow racing with X, or is that in joyride only?
>>
>> Sorry, not sure. I'm back on joyride now and Browse seems quite happy
>> there.
>
> I was away from the web earlier and couldn't look up the trac for what
> I was referring to: http://dev.laptop.org/ticket/6797 (in case it
> happens again).

Martin, thanks for your suggestion.

OK, I've just gone back and re-installed 706 again on the B4 I have  
here to give this another try.

Browse v86 is still failing to launch after repeated reboots. I've  
added the content of its log file to the end of this email. BTW: using  
cat on the file was a good hint as you get to see its content color  
coded, pity Log activity doesn't interpret them the same way (Log  
shows all the nasty console escape codes).

No idea if "rainbow racing with X" was a red-herring or not, ticket  
6797 didn't say what to expect to see from such a condition, or how to  
test for it. Seeing as Browse consistently fails to launch, a race  
condition seems less plausible to me, I'd expect a race condition to  
occasionally have a different outcome.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Dengler | 2 Jun 02:29
Gravatar

Re: Capturing all mouse events

On Fri, May 30, 2008 at 09:38:39PM -0400, Benjamin M. Schwartz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Does anyone know how to capture all mouse events?

In trying to do this with pygtk, we both have run into gtk bug
#156948[1] - for the record/to close the loop, we tried calling
add_filter() on gtk.gdk.get_default_root_window()'s returned
gtk.gdk.Window. This should, in theory, give us all events[2]. But the
bug prevents the information from being useful, and it's not clear
that we're really getting all events[3].

> [...] listen to /dev/input/mouse0.

That seems promising.  I couldn't find anything useful in pygame.

> - --Ben

Martin

1. http://bugzilla.gnome.org/show_bug.cgi?id=156948
2. this is what metacity uses:

--- metacity-2.23.0/src/ui/ui.c:76
static GdkFilterReturn
filter_func (GdkXEvent *xevent,
             GdkEvent *event,
             gpointer data)
{
(Continue reading)

Permalink | Reply | 4 comments |
headers
Benjamin M. Schwartz | 2 Jun 03:05
Picon

Re: Capturing all mouse events


Martin Dengler wrote:
| On Fri, May 30, 2008 at 09:38:39PM -0400, Benjamin M. Schwartz wrote:
|>
|> Does anyone know how to capture all mouse events?
|
| In trying to do this with pygtk, we both have run into gtk bug
| #156948[1] - for the record/to close the loop, we tried calling
| add_filter() on gtk.gdk.get_default_root_window()'s returned
| gtk.gdk.Window. This should, in theory, give us all events[2]. But the
| bug prevents the information from being useful, and it's not clear
| that we're really getting all events[3].

I've been trying to use the RECORD extension, which provides access to ALL
input events in a simple way.  Unfortunately, I can't seem to load the
RECORD extension.  I have added the line

Load "record"

to my xorg.conf, and my Xorg.0.log now shows a line

(II) Loading extension RECORD

but xdpyinfo doesn't show RECORD in its list of loaded extensions.

Why won't Record load?

--Ben
Permalink | Reply | 2 comments |
headers
Martin Dengler | 2 Jun 03:15
Gravatar

Re: Capturing all mouse events

On Sun, Jun 01, 2008 at 09:05:48PM -0400, Benjamin M. Schwartz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Martin Dengler wrote:
> | On Fri, May 30, 2008 at 09:38:39PM -0400, Benjamin M. Schwartz wrote:
> |>
> |> Does anyone know how to capture all mouse events?
> |
> | In trying to do this with pygtk, we both have run into gtk bug
> | #156948[1] - for the record/to close the loop, we tried calling
> | add_filter() on gtk.gdk.get_default_root_window()'s returned
> | gtk.gdk.Window. This should, in theory, give us all events[2]. But the
> | bug prevents the information from being useful, and it's not clear
> | that we're really getting all events[3].
> 
> I've been trying to use the RECORD extension, which provides access to ALL
> input events in a simple way.  Unfortunately, I can't seem to load the
> RECORD extension.  I have added the line
> 
> Load "record"
> 
> to my xorg.conf, and my Xorg.0.log now shows a line
> 
> (II) Loading extension RECORD
> 
> but xdpyinfo doesn't show RECORD in its list of loaded extensions.

Me too...it was already in xorg.conf, so we must be doing something
wrong...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Schampijer | 2 Jun 12:00
Picon

Notes from Linuxtag 2008

Members of the sugar community [1] met this weekend at the Linuxtag 2008 [2] in 
Berlin, Germany. Besides meeting people in person and the usual putting faces to 
names we discussed the current situation of sugar.

Hot topics were what work is left to run sugar on multiple platforms (e.g. the Asus 
eee pc) and the structure Sugar Labs needs to have to fulfill this expectation. We 
met as well with Jim Gettys and had an interesting interchange of ideas.

Thanks to OLPC Germany and especially to Holger Levsen we had the opportunity to 
give an introduction into sugar to the winners of an Idea Contest [3]. Robert Krahn 
gave a tutorial about using Squeak on the XO and Wolfgang Rohrmoser handed out a 
XO-Live CD to people who were interested in trying out sugar on their machines.

It was nice meeting you all and hope to see you soon again,
    Simon

[1] Group photo 
http://wiki.sugarlabs.org/go/Image:LinuxTag-2008-Bernie-Reinier-Marco-Simon-Bert-Tomeu.jpg
[2] Linuxtag http://www.linuxtag.org/2008/
[3] 
http://wiki.olpc-deutschland.de/Start?action=AttachFile&do=view&target=LinuxTag-2008-OLPC-Deutschland-Developers.jpg
[4] ftp://rohrmoser-engineering.de/pub/XO-LiveCD/
Permalink | Reply | 0 comments |
headers
Tomeu Vizoso | 2 Jun 12:08

control panel review

Hi,

yesterday had a bunch of hours in the train, so decided to give a look
to Simon's work on the control panel. I think he has done a great work
and would love to see it ASAP on the builds.

Please take in account that most of the comments are style nitpicks of
me that other people may not share.

cmd.py

    '''Print the help to the screen'''
s/the/

    print _('To apply your changes you have to restart sugar.\n' +
            'Hit ctrl+alt+erase on the keyboard to trigger a restart.')
Should we tell to close first the activities so no data is lost?

    names = os.listdir(os.path.join(config.shell_path, '/'.join(subpath)))
s/names/file_names

    modules = []
    for name in names:
s/name/file_name

        if name.endswith('.py') and name != '__init__.py':
            tmp = name.strip('.py')
s/tmp/module_name

            mod = __import__('.'.join(subpath) + '.' +
(Continue reading)

Permalink | Reply | 6 comments |
headers
Sayamindu Dasgupta | 2 Jun 12:37
Picon
Gravatar

Re: Experiments with Metacity

Hi,

On Mon, May 19, 2008 at 5:14 PM, Marco Pesenti Gritti
<mpgritti <at> gmail.com> wrote:
> On Mon, May 19, 2008 at 11:41 AM, Marco Pesenti Gritti
> <mpgritti <at> gmail.com> wrote:
>> Maximize + undecorated might work. It has to be done by each activity.
>
> We could add an option to make metacity show *no* decoration for
> maximized windows. As long as we have a Close menu on the frame that
> should be desired also for desktop applications.
>
> Ideally we could figure out a way to make metacity maximize activity
> windows by default, but I can't think of a clean way to do it. One
> problem with doing the maximize in the activity is that it would still
> do so when running on a normal desktop.
>

I tried the alternative of modifying metacity instead of playing
around with the activities.
My plan is to make metacity behave a little differently (ie: maximize
and undecorate any window with the hint GDK_WINDOW_TYPE_HINT_NORMAL,
as suggested by Marco in
http://wiki.sugarlabs.org/go/WindowManagement) when it runs inside
Sugar. For this, I think a possible way forward is to have
olpc-session export a environment variable SUGAR_SESSION_RUNNING=1,
which would be checked by metacity before it goes into the "sugary
mode" [1]. Does this sound sane ?

For now, I have implemented this (sans the check for
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tomeu Vizoso | 2 Jun 13:05

Re: [PATCH] Fix #6994 - Add speaker device and icon by default

On Fri, May 30, 2008 at 5:07 PM, Martin Dengler
<martin <at> martindengler.com> wrote:
> Fix #6994 - Add speaker device and icon by default, as in
> http://wiki.laptop.org/go/Designs/Frame#07

Pushed, thanks a lot!

Tomeu
Permalink | Reply | 0 comments |
headers
Guillaume Desmottes | 2 Jun 13:41
Picon

Gadget's feature integration in Sugar

Hi,

Daf and I are making good progress on Gadget, so that's a good time to
start to think about its integration in Sugar.

Basically, Gadget is a XMPP server component that should solve our
current scalability issues and drop the ugly "shared roster" hack.
I invite you to take a look on the "Use Cases" and "Design Goals"
sections of http://wiki.laptop.org/go/XMPP_Component_Protocol to have a
better idea of what Gadget is and which problem it tries to solve.

Here is a list of few points that should be discussed about their sugar
integration.

- We need GUI to perform buddy searches. Buddies can be searched using
their properties (color, key, jid).

- We also need GUI to perform Activity searches. Activities can be
searched using their properties (color, name, type, tags) or their
participants (based on their jid).

I guess these searches should be done directly from the mesh view. How
should we expose the different type of search in the GUI?

- As we intent to drop the shared buddy server hack, people won't see
all the buddies connected on the server anymore.
They'll see their friends, the result of the active searches and a
maximum of $N random buddies and $N' random activities.

Should we hardcode the value of this $N? Make it configurable from the
(Continue reading)

Permalink | Reply | 6 comments |
headers
Benjamin M. Schwartz | 2 Jun 17:04
Picon

Re: Experiments with Metacity


Sayamindu Dasgupta wrote:
| Hi,
|
| On Mon, May 19, 2008 at 5:14 PM, Marco Pesenti Gritti
| <mpgritti <at> gmail.com> wrote:
|> On Mon, May 19, 2008 at 11:41 AM, Marco Pesenti Gritti
|> <mpgritti <at> gmail.com> wrote:
|>> Maximize + undecorated might work. It has to be done by each activity.
|> We could add an option to make metacity show *no* decoration for
|> maximized windows. As long as we have a Close menu on the frame that
|> should be desired also for desktop applications.
|>
|> Ideally we could figure out a way to make metacity maximize activity
|> windows by default, but I can't think of a clean way to do it. One
|> problem with doing the maximize in the activity is that it would still
|> do so when running on a normal desktop.
|>
|
| I tried the alternative of modifying metacity instead of playing
| around with the activities.
| My plan is to make metacity behave a little differently (ie: maximize
| and undecorate any window with the hint GDK_WINDOW_TYPE_HINT_NORMAL,
| as suggested by Marco in
| http://wiki.sugarlabs.org/go/WindowManagement) when it runs inside
| Sugar. For this, I think a possible way forward is to have
| olpc-session export a environment variable SUGAR_SESSION_RUNNING=1,
| which would be checked by metacity before it goes into the "sugary
| mode" [1]. Does this sound sane ?
(Continue reading)

Permalink | Reply | 2 comments |

Gmane