Re: [Sugar-devel] TamTam port to gtk3, round 2
Great. We can coordinate by irc if you want. Gonzalo On Sat, Jan 26, 2013 at 11:07 AM, Ignacio Rodríguez nachoe...@gmail.comwrote: Gonzalo. I join. 2013/1/25 Gonzalo Odiard gonz...@laptop.org I continued working in the port of TamTam to Gtk3. This week, started to work in TamTamJam, is not ready yet, but the activity starts and is possible see something in the screen. More work is needed. All is pushed to master branch. Brave hackers interested, please coordinate by mail or irc with me. Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Saludos Juan Ignacio Rodríguez *CeibalJAM!* *Somos Azucar* ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
Hi all.
A simple solution was found :)
I hacked the KP_Prior and KP_Next keys, and now they are used for
making-window-smaller and restoring-original-window-size respectively :)
All thanks to
* /usr/share/X11/xkb/keycodes/evdev
* sugar/src/jarabe/view/keyhandler.py
Just one thing I noticed when I tried to have the above keys take effect
ONLY in ebook-mode (via the evtest --query test), that when I ran this
again and again via the suprocess module, the XO-4 behaved very
erratically. However, when I made the keys take effect irrespective of the
test of ebook-mode, things worked cool. However, I will keep on looking
into the reason.
Thanks a ton to all :)
On Thu, Jan 24, 2013 at 10:45 PM, Paul Fox p...@laptop.org wrote:
gonzalo wrote:
Write does not know what is the ebook switch state, that logic is in the
osk.
Looking in the wiki and sugar code, I could not find information about
how
read the switch,
but in ticket http://dev.laptop.org/ticket/12326 found this:
If you do:
evtest --query /dev/input/event4 EV_SW SW_TABLET_MODE; echo $?
If the xo is in ebook mode returns 10, if not, returns 0.
There are any official doc about the switches I am missing? There are a
way
to catch a event when the switch is activated, using dbus or something
similar?
if you open the device and read it, you'll get a stream of struct
input_event structures (/usr/include/linux/input.h) representing
opening and closing of the SW_TABLET_MODE switch. here's a C code
snippet from olpc-switchd (part of powerd):
void ebook_event()
{
struct input_event ev[1];
if (read(ebk_fd, ev, sizeof(ev)) != sizeof(ev))
die(bad read from ebook switch);
dbg(3, ebk: ev sec %d usec %d type %d code %d value %d,
ev-time.tv_sec, ev-time.tv_usec,
ev-type, ev-code, ev-value);
if (ev-type == EV_SW ev-code == SW_TABLET_MODE) {
if (ev-value)
send_event(ebookclose, round_secs(ev), ebk_device);
else
send_event(ebookopen, round_secs(ev), ebk_device);
}
}
perhaps there's an evdev to dbus gateway of some sort, but i don't know
about it, if so.
the evtest commandline example, above, uses an ioctl on the input
device to determine current state. here's snippet from the evtest source:
(full source: git://anongit.freedesktop.org/evtest)
static int query_device(const char *device, const struct query_mode
*query_mode
{
int fd;
int r;
unsigned long state[NBITS(query_mode-max)];
fd = open(device, O_RDONLY);
if (fd 0) {
perror(open);
return EXIT_FAILURE;
}
memset(state, 0, sizeof(state));
r = ioctl(fd, query_mode-rq, state);
close(fd);
if (r == -1) {
perror(ioctl);
return EXIT_FAILURE;
}
if (test_bit(keycode, state))
return 10; /* different from EXIT_FAILURE */
else
return 0;
}
paul
Gonzalo
On Thu, Jan 24, 2013 at 12:16 PM, Martin Langhoff
martin.langh...@gmail.com
wrote:
On Thu, Jan 24, 2013 at 10:13 AM, Paul Fox p...@laptop.org wrote:
i believe sugar already has code to detect the two modes, since
that's how it knows whether to present the OSK or not.
Yep. Ajay, I think Write shows you the way :-)
m
--
martin.langh...@gmail.com
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
=-
paul fox, p...@laptop.org
___
Devel mailing list
de...@lists.laptop.org
http://lists.laptop.org/listinfo/devel
--
Regards,
Ajay Garg
Dextrose Developer
Activity Central: http://activitycentral.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
Hey Daniel, thanks for the writeup! On 01/26/2013 03:27 PM, Daniel Narvaez wrote: Hello, the desire to be able to write activities using html has been expressed several times by developers. We have seen several approaches but there is not much support for it in the core platform yet. I and Simon have been trying to figure out how to best integrate this with the existing platform. Bits of code can be pulled from the sugar-build html branch. We don't have much of a demo yet, but I think the basic pieces of the infrastucture are becoming clear, so I thought it would be good to try and summarize them in an email to the list. 1 sugar-toolkit-html * A new module. * Independent from the native sugar API, so that html activities might be run on other platforms, like Android or even inside a web browser. * HTML equivalents of the gtk widgets. For example Toolbar and Palette. * Per-platform (sugar-os, android, web-browser...) implementations of the same javascript interface to the sugar services. For example it might provide a datastore.save(metadata, file) method or an icon.get_with_colors(xo_colors) 2 sugar-http-server * A sugar-os internal component. Other platforms might implement the html/javascript API without even using an http server. * Implemented by the sugar-toolkit-html module but managed by the sugar shell. * Serves the activity bundles content with something like http://localhost:8000/org.sugarlabs.HTMLDemo/index.html. * Exposes the sugar services API with json methods like http://localhost:8000/org.sugarlabs.HTMLDemo/datastore/save As we talked about today, I was looking at node-dbus [1] in order to talk to the DS over dbus from java script. Looks straight forward. I installed the module (npm install node-dbus) and did a quick example based on the test in the repo to listen on the 'Created' signal from the DS. Works fine. Of course, if we use nodejs we have to handle the modules packaging as nodejs itself is rather limited and a most of the functionality is in the modules. Cheers, Simon [1] https://npmjs.org/package/node-dbus test-ds-listener.js Description: application/javascript ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
ajay wrote:
Hi all.
A simple solution was found :)
I hacked the KP_Prior and KP_Next keys, and now they are used for
making-window-smaller and restoring-original-window-size respectively :)
so sugar takes over those keys? aren't those keys used by activities?
they're certainly useful in a terminal -- page up and page down.
paul
All thanks to
* /usr/share/X11/xkb/keycodes/evdev
* sugar/src/jarabe/view/keyhandler.py
Just one thing I noticed when I tried to have the above keys take effect
ONLY in ebook-mode (via the evtest --query test), that when I ran this
again and again via the suprocess module, the XO-4 behaved very
erratically. However, when I made the keys take effect irrespective of the
test of ebook-mode, things worked cool. However, I will keep on looking
into the reason.
Thanks a ton to all :)
On Thu, Jan 24, 2013 at 10:45 PM, Paul Fox p...@laptop.org wrote:
gonzalo wrote:
Write does not know what is the ebook switch state, that logic is in the
osk.
Looking in the wiki and sugar code, I could not find information about
how
read the switch,
but in ticket http://dev.laptop.org/ticket/12326 found this:
If you do:
evtest --query /dev/input/event4 EV_SW SW_TABLET_MODE; echo $?
If the xo is in ebook mode returns 10, if not, returns 0.
There are any official doc about the switches I am missing? There are a
way
to catch a event when the switch is activated, using dbus or something
similar?
if you open the device and read it, you'll get a stream of struct
input_event structures (/usr/include/linux/input.h) representing
opening and closing of the SW_TABLET_MODE switch. here's a C code
snippet from olpc-switchd (part of powerd):
void ebook_event()
{
struct input_event ev[1];
if (read(ebk_fd, ev, sizeof(ev)) != sizeof(ev))
die(bad read from ebook switch);
dbg(3, ebk: ev sec %d usec %d type %d code %d value %d,
ev-time.tv_sec, ev-time.tv_usec,
ev-type, ev-code, ev-value);
if (ev-type == EV_SW ev-code == SW_TABLET_MODE) {
if (ev-value)
send_event(ebookclose, round_secs(ev), ebk_device);
else
send_event(ebookopen, round_secs(ev), ebk_device);
}
}
perhaps there's an evdev to dbus gateway of some sort, but i don't know
about it, if so.
the evtest commandline example, above, uses an ioctl on the input
device to determine current state. here's snippet from the evtest source:
(full source: git://anongit.freedesktop.org/evtest)
static int query_device(const char *device, const struct query_mode
*query_mode
{
int fd;
int r;
unsigned long state[NBITS(query_mode-max)];
fd = open(device, O_RDONLY);
if (fd 0) {
perror(open);
return EXIT_FAILURE;
}
memset(state, 0, sizeof(state));
r = ioctl(fd, query_mode-rq, state);
close(fd);
if (r == -1) {
perror(ioctl);
return EXIT_FAILURE;
}
if (test_bit(keycode, state))
return 10; /* different from EXIT_FAILURE */
else
return 0;
}
paul
Gonzalo
On Thu, Jan 24, 2013 at 12:16 PM, Martin Langhoff
martin.langh...@gmail.com
wrote:
On Thu, Jan 24, 2013 at 10:13 AM, Paul Fox p...@laptop.org wrote:
i believe sugar already has code to detect the two modes, since
that's how it knows whether to present the OSK or not.
Yep. Ajay, I think Write shows you the way :-)
m
--
martin.langh...@gmail.com
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
=-
paul fox, p...@laptop.org
___
Devel mailing list
de...@lists.laptop.org
http://lists.laptop.org/listinfo/devel
--
Regards,
Ajay Garg
Dextrose Developer
Activity Central: http://activitycentral.com
=-
paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On Mon, Jan 28, 2013 at 5:30 PM, Simon Schampijer si...@schampijer.de wrote: Hey Daniel, thanks for the writeup! On 01/26/2013 03:27 PM, Daniel Narvaez wrote: Hello, the desire to be able to write activities using html has been expressed several times by developers. We have seen several approaches but there is not much support for it in the core platform yet. I and Simon have been trying to figure out how to best integrate this with the existing platform. Bits of code can be pulled from the sugar-build html branch. We don't have much of a demo yet, but I think the basic pieces of the infrastucture are becoming clear, so I thought it would be good to try and summarize them in an email to the list. 1 sugar-toolkit-html * A new module. * Independent from the native sugar API, so that html activities might be run on other platforms, like Android or even inside a web browser. * HTML equivalents of the gtk widgets. For example Toolbar and Palette. * Per-platform (sugar-os, android, web-browser...) implementations of the same javascript interface to the sugar services. For example it might provide a datastore.save(metadata, file) method or an icon.get_with_colors(xo_colors) 2 sugar-http-server * A sugar-os internal component. Other platforms might implement the html/javascript API without even using an http server. * Implemented by the sugar-toolkit-html module but managed by the sugar shell. * Serves the activity bundles content with something like http://localhost:8000/org.sugarlabs.HTMLDemo/index.html. * Exposes the sugar services API with json methods like http://localhost:8000/org.sugarlabs.HTMLDemo/datastore/save As we talked about today, I was looking at node-dbus [1] in order to talk to the DS over dbus from java script. Looks straight forward. I installed the module (npm install node-dbus) and did a quick example based on the test in the repo to listen on the 'Created' signal from the DS. Works fine. Of course, if we use nodejs we have to handle the modules packaging as nodejs itself is rather limited and a most of the functionality is in the modules. There's 100s of them currently being packaged for Fedora, there's about 50 in F-18 already, I think a lot more (maybe it just seems that way from the build reports) in F-19. yum list nodejs* will give you more details. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
Hi Daniel, Here my suggestions experimented on my own framework [1]. 3 sugar-html-activity In my opinion, it's the easy way to do. * Toolbar widget using the icons API, perhaps without palettes. Yes but we should allow developers to use a true Python toolbar instead of the simple one when needed. * Datastore saving and loading. I've already implemented it in a simple API. With two methods: save a JavaScript object, load a JavaScript object, we could probably cover 90% of the need. * The rest of the UI widgets. Not sure to see the interest to port the UI widgets. HTML activities will just draw their widgets using their own framework (or standard HTML widget). Of course it will be visually different from Sugar widgets but I don't think its an issue. * Should we be using existing js frameworks like jquery in the toolkit ot limit ourselves to plain javascript. There is plenty of JavaScript frameworks. We should allow to use any framework to avoid losing a part of the JavaScript community. My current work is based on the Enyo framework but could be adapted easily to jQuery or to pure JavaScript. * How do we limit access to the http server. Can one activity access the files of another one? No HTTP server need in a pure HTML activity. * Should we try to ease the transition from native to html activities, allowing for example to use native toolbars? In my opinion, it's very important to allow developers to expand the JavaScript code with Python code when need. I think this has a lot potential because it allows to run activities pretty much everywhere (if nothing else inside a web browser). At the same time it allows to support services like datastore which are an essential part of the sugar experience. Finally it gives powerful new tools to activity developers, HTML being much more expressive than gtk. +1 Lionel. [1] http://booki.flossmanuals.net/make-your-own-sugar-activities/_draft/_v/1.0/d eveloping-sugar-activities-using-html5/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Mon, Jan 28, 2013 at 11:01 PM, Paul Fox p...@laptop.org wrote:
ajay wrote:
Hi all.
A simple solution was found :)
I hacked the KP_Prior and KP_Next keys, and now they are used for
making-window-smaller and restoring-original-window-size respectively :)
so sugar takes over those keys? aren't those keys used by activities?
they're certainly useful in a terminal -- page up and page down.
Hmm.. Well a simple grepping showed that the Read activity is the only
activity that explicitly makes use of the KP_Home and KP_End keys; but
none seemed to make use of KP_Prior and KP_Next.
paul
All thanks to
* /usr/share/X11/xkb/keycodes/evdev
* sugar/src/jarabe/view/keyhandler.py
Just one thing I noticed when I tried to have the above keys take
effect
ONLY in ebook-mode (via the evtest --query test), that when I ran this
again and again via the suprocess module, the XO-4 behaved very
erratically. However, when I made the keys take effect irrespective of
the
test of ebook-mode, things worked cool. However, I will keep on looking
into the reason.
Thanks a ton to all :)
On Thu, Jan 24, 2013 at 10:45 PM, Paul Fox p...@laptop.org wrote:
gonzalo wrote:
Write does not know what is the ebook switch state, that logic is
in the
osk.
Looking in the wiki and sugar code, I could not find information
about
how
read the switch,
but in ticket http://dev.laptop.org/ticket/12326 found this:
If you do:
evtest --query /dev/input/event4 EV_SW SW_TABLET_MODE; echo $?
If the xo is in ebook mode returns 10, if not, returns 0.
There are any official doc about the switches I am missing? There
are a
way
to catch a event when the switch is activated, using dbus or
something
similar?
if you open the device and read it, you'll get a stream of struct
input_event structures (/usr/include/linux/input.h) representing
opening and closing of the SW_TABLET_MODE switch. here's a C code
snippet from olpc-switchd (part of powerd):
void ebook_event()
{
struct input_event ev[1];
if (read(ebk_fd, ev, sizeof(ev)) != sizeof(ev))
die(bad read from ebook switch);
dbg(3, ebk: ev sec %d usec %d type %d code %d value %d,
ev-time.tv_sec, ev-time.tv_usec,
ev-type, ev-code, ev-value);
if (ev-type == EV_SW ev-code == SW_TABLET_MODE) {
if (ev-value)
send_event(ebookclose, round_secs(ev), ebk_device);
else
send_event(ebookopen, round_secs(ev), ebk_device);
}
}
perhaps there's an evdev to dbus gateway of some sort, but i don't
know
about it, if so.
the evtest commandline example, above, uses an ioctl on the input
device to determine current state. here's snippet from the evtest
source:
(full source: git://anongit.freedesktop.org/evtest)
static int query_device(const char *device, const struct
query_mode
*query_mode
{
int fd;
int r;
unsigned long state[NBITS(query_mode-max)];
fd = open(device, O_RDONLY);
if (fd 0) {
perror(open);
return EXIT_FAILURE;
}
memset(state, 0, sizeof(state));
r = ioctl(fd, query_mode-rq, state);
close(fd);
if (r == -1) {
perror(ioctl);
return EXIT_FAILURE;
}
if (test_bit(keycode, state))
return 10; /* different from EXIT_FAILURE */
else
return 0;
}
paul
Gonzalo
On Thu, Jan 24, 2013 at 12:16 PM, Martin Langhoff
martin.langh...@gmail.com
wrote:
On Thu, Jan 24, 2013 at 10:13 AM, Paul Fox p...@laptop.org
wrote:
i believe sugar already has code to detect the two modes, since
that's how it knows whether to present the OSK or not.
Yep. Ajay, I think Write shows you the way :-)
m
--
martin.langh...@gmail.com
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
=-
paul fox, p...@laptop.org
___
Devel mailing list
de...@lists.laptop.org
http://lists.laptop.org/listinfo/devel
--
Regards,
Ajay Garg
Dextrose Developer
Activity
Re: [Sugar-devel] HTML activities
On 01/28/2013 06:37 PM, Peter Robinson wrote: On Mon, Jan 28, 2013 at 5:30 PM, Simon Schampijer si...@schampijer.de wrote: Hey Daniel, thanks for the writeup! On 01/26/2013 03:27 PM, Daniel Narvaez wrote: Hello, the desire to be able to write activities using html has been expressed several times by developers. We have seen several approaches but there is not much support for it in the core platform yet. I and Simon have been trying to figure out how to best integrate this with the existing platform. Bits of code can be pulled from the sugar-build html branch. We don't have much of a demo yet, but I think the basic pieces of the infrastucture are becoming clear, so I thought it would be good to try and summarize them in an email to the list. 1 sugar-toolkit-html * A new module. * Independent from the native sugar API, so that html activities might be run on other platforms, like Android or even inside a web browser. * HTML equivalents of the gtk widgets. For example Toolbar and Palette. * Per-platform (sugar-os, android, web-browser...) implementations of the same javascript interface to the sugar services. For example it might provide a datastore.save(metadata, file) method or an icon.get_with_colors(xo_colors) 2 sugar-http-server * A sugar-os internal component. Other platforms might implement the html/javascript API without even using an http server. * Implemented by the sugar-toolkit-html module but managed by the sugar shell. * Serves the activity bundles content with something like http://localhost:8000/org.sugarlabs.HTMLDemo/index.html. * Exposes the sugar services API with json methods like http://localhost:8000/org.sugarlabs.HTMLDemo/datastore/save As we talked about today, I was looking at node-dbus [1] in order to talk to the DS over dbus from java script. Looks straight forward. I installed the module (npm install node-dbus) and did a quick example based on the test in the repo to listen on the 'Created' signal from the DS. Works fine. I added as well an example for dbus methods, you can delete DS entries now :) http://dev.laptop.org/~erikos/html-activity/ Of course, if we use nodejs we have to handle the modules packaging as nodejs itself is rather limited and a most of the functionality is in the modules. There's 100s of them currently being packaged for Fedora, there's about 50 in F-18 already, I think a lot more (maybe it just seems that way from the build reports) in F-19. yum list nodejs* will give you more details. Perfect, that is good news. This reminds me that I should switch to F18 now...:) Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH sugar-toolkit-gtk3 1/2] Remove duplicated library flags
From: Daniel Narvaez dwnarv...@gmail.com They are already provided by the pc files. --- src/sugar3/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/sugar3/Makefile.am b/src/sugar3/Makefile.am index 5db2c20..ddea9c8 100644 --- a/src/sugar3/Makefile.am +++ b/src/sugar3/Makefile.am @@ -19,7 +19,7 @@ libsugarext_la_CFLAGS = \ $(WARN_CFLAGS) libsugarext_la_LDFLAGS = $(LDADD) -libsugarext_la_LIBADD = $(EXT_LIBS) -lSM -lICE -lasound +libsugarext_la_LIBADD = $(EXT_LIBS) libsugarext_la_SOURCES = \ $(BUILT_SOURCES)\ -- 1.8.1 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
ajay wrote:
On Mon, Jan 28, 2013 at 11:01 PM, Paul Fox p...@laptop.org wrote:
ajay wrote:
Hi all.
A simple solution was found :)
I hacked the KP_Prior and KP_Next keys, and now they are used for
making-window-smaller and restoring-original-window-size respectively :)
so sugar takes over those keys? aren't those keys used by activities?
they're certainly useful in a terminal -- page up and page down.
Hmm.. Well a simple grepping showed that the Read activity is the only
activity that explicitly makes use of the KP_Home and KP_End keys; but
none seemed to make use of KP_Prior and KP_Next.
certainly not my call, but stealing keys which have always been
intended for activities to use seems like it shouldn't be done
lightly.
(and why do you need two keys? isn't the operation a toggle?)
paul
paul
All thanks to
* /usr/share/X11/xkb/keycodes/evdev
* sugar/src/jarabe/view/keyhandler.py
Just one thing I noticed when I tried to have the above keys take
effect
ONLY in ebook-mode (via the evtest --query test), that when I ran this
again and again via the suprocess module, the XO-4 behaved very
erratically. However, when I made the keys take effect irrespective of
the
test of ebook-mode, things worked cool. However, I will keep on looking
into the reason.
Thanks a ton to all :)
On Thu, Jan 24, 2013 at 10:45 PM, Paul Fox p...@laptop.org wrote:
gonzalo wrote:
Write does not know what is the ebook switch state, that logic is
in the
osk.
Looking in the wiki and sugar code, I could not find information
about
how
read the switch,
but in ticket http://dev.laptop.org/ticket/12326 found this:
If you do:
evtest --query /dev/input/event4 EV_SW SW_TABLET_MODE; echo $?
If the xo is in ebook mode returns 10, if not, returns 0.
There are any official doc about the switches I am missing? There
are a
way
to catch a event when the switch is activated, using dbus or
something
similar?
if you open the device and read it, you'll get a stream of struct
input_event structures (/usr/include/linux/input.h) representing
opening and closing of the SW_TABLET_MODE switch. here's a C code
snippet from olpc-switchd (part of powerd):
void ebook_event()
{
struct input_event ev[1];
if (read(ebk_fd, ev, sizeof(ev)) != sizeof(ev))
die(bad read from ebook switch);
dbg(3, ebk: ev sec %d usec %d type %d code %d value %d,
ev-time.tv_sec, ev-time.tv_usec,
ev-type, ev-code, ev-value);
if (ev-type == EV_SW ev-code == SW_TABLET_MODE) {
if (ev-value)
send_event(ebookclose, round_secs(ev), ebk_device);
else
send_event(ebookopen, round_secs(ev), ebk_device);
}
}
perhaps there's an evdev to dbus gateway of some sort, but i don't
know
about it, if so.
the evtest commandline example, above, uses an ioctl on the input
device to determine current state. here's snippet from the evtest
source:
(full source: git://anongit.freedesktop.org/evtest)
static int query_device(const char *device, const struct
query_mode
*query_mode
{
int fd;
int r;
unsigned long state[NBITS(query_mode-max)];
fd = open(device, O_RDONLY);
if (fd 0) {
perror(open);
return EXIT_FAILURE;
}
memset(state, 0, sizeof(state));
r = ioctl(fd, query_mode-rq, state);
close(fd);
if (r == -1) {
perror(ioctl);
return EXIT_FAILURE;
}
if (test_bit(keycode, state))
return 10; /* different from EXIT_FAILURE */
else
return 0;
}
paul
Gonzalo
On Thu, Jan 24, 2013 at 12:16 PM, Martin Langhoff
martin.langh...@gmail.com
wrote:
On Thu, Jan 24, 2013 at 10:13 AM, Paul Fox p...@laptop.org
wrote:
i believe sugar already has code to detect the two modes, since
that's how it knows whether to present the OSK or not.
Yep. Ajay, I think Write shows you the way :-)
m
--
[Sugar-devel] [PATCH sugar-toolkit-gtk3 2/2] Add missing dependencies
From: Daniel Narvaez dwnarv...@gmail.com I'm not sure how it works with GNU ld, but it breaks with ld gold and it's clearly wrong anyway. --- configure.ac | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index cb221a8..fefb8e8 100644 --- a/configure.ac +++ b/configure.ac @@ -20,7 +20,8 @@ AM_CHECK_PYTHON_HEADERS(,[AC_MSG_ERROR(could not find Python headers)]) AC_PATH_PROG(PYGTK_CODEGEN, pygtk-codegen-2.0, no) -PKG_CHECK_MODULES(EXT, gtk+-3.0 gdk-3.0 gdk-pixbuf-2.0 sm ice alsa librsvg-2.0) +PKG_CHECK_MODULES(EXT, gtk+-3.0 gdk-3.0 gdk-pixbuf-2.0 sm ice alsa + librsvg-2.0 xfixes xi x11) PYGTK_DEFSDIR=`$PKG_CONFIG --variable=defsdir pygtk-2.0` AC_SUBST(PYGTK_DEFSDIR) -- 1.8.1 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3 2/2] Add missing dependencies
On 01/28/2013 07:16 PM, Daniel Narvaez wrote: From: Daniel Narvaez dwnarv...@gmail.com I'm not sure how it works with GNU ld, but it breaks with ld gold and it's clearly wrong anyway. --- configure.ac | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index cb221a8..fefb8e8 100644 --- a/configure.ac +++ b/configure.ac @@ -20,7 +20,8 @@ AM_CHECK_PYTHON_HEADERS(,[AC_MSG_ERROR(could not find Python headers)]) AC_PATH_PROG(PYGTK_CODEGEN, pygtk-codegen-2.0, no) -PKG_CHECK_MODULES(EXT, gtk+-3.0 gdk-3.0 gdk-pixbuf-2.0 sm ice alsa librsvg-2.0) +PKG_CHECK_MODULES(EXT, gtk+-3.0 gdk-3.0 gdk-pixbuf-2.0 sm ice alsa + librsvg-2.0 xfixes xi x11) PYGTK_DEFSDIR=`$PKG_CONFIG --variable=defsdir pygtk-2.0` AC_SUBST(PYGTK_DEFSDIR) Both patches look good, please push. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Mon, Jan 28, 2013 at 2:50 PM, Ajay Garg a...@activitycentral.com wrote:
On Mon, Jan 28, 2013 at 11:01 PM, Paul Fox p...@laptop.org wrote:
ajay wrote:
Hi all.
A simple solution was found :)
I hacked the KP_Prior and KP_Next keys, and now they are used for
making-window-smaller and restoring-original-window-size respectively
:)
so sugar takes over those keys? aren't those keys used by activities?
they're certainly useful in a terminal -- page up and page down.
Hmm.. Well a simple grepping showed that the Read activity is the only
activity that explicitly makes use of the KP_Home and KP_End keys; but
none seemed to make use of KP_Prior and KP_Next.
A simple grep is not good enough. Gtk already uses these keys, for example
in a textview.
I can't understand what you are trying to do. The user should press the key
to enlarge/shrink the activity window? Does not look like a good solution.
Gonzalo
paul
All thanks to
* /usr/share/X11/xkb/keycodes/evdev
* sugar/src/jarabe/view/keyhandler.py
Just one thing I noticed when I tried to have the above keys take
effect
ONLY in ebook-mode (via the evtest --query test), that when I ran
this
again and again via the suprocess module, the XO-4 behaved very
erratically. However, when I made the keys take effect irrespective of
the
test of ebook-mode, things worked cool. However, I will keep on looking
into the reason.
Thanks a ton to all :)
On Thu, Jan 24, 2013 at 10:45 PM, Paul Fox p...@laptop.org wrote:
gonzalo wrote:
Write does not know what is the ebook switch state, that logic is
in the
osk.
Looking in the wiki and sugar code, I could not find information
about
how
read the switch,
but in ticket http://dev.laptop.org/ticket/12326 found this:
If you do:
evtest --query /dev/input/event4 EV_SW SW_TABLET_MODE; echo $?
If the xo is in ebook mode returns 10, if not, returns 0.
There are any official doc about the switches I am missing? There
are a
way
to catch a event when the switch is activated, using dbus or
something
similar?
if you open the device and read it, you'll get a stream of struct
input_event structures (/usr/include/linux/input.h) representing
opening and closing of the SW_TABLET_MODE switch. here's a C code
snippet from olpc-switchd (part of powerd):
void ebook_event()
{
struct input_event ev[1];
if (read(ebk_fd, ev, sizeof(ev)) != sizeof(ev))
die(bad read from ebook switch);
dbg(3, ebk: ev sec %d usec %d type %d code %d value %d,
ev-time.tv_sec, ev-time.tv_usec,
ev-type, ev-code, ev-value);
if (ev-type == EV_SW ev-code == SW_TABLET_MODE) {
if (ev-value)
send_event(ebookclose, round_secs(ev), ebk_device);
else
send_event(ebookopen, round_secs(ev), ebk_device);
}
}
perhaps there's an evdev to dbus gateway of some sort, but i don't
know
about it, if so.
the evtest commandline example, above, uses an ioctl on the input
device to determine current state. here's snippet from the evtest
source:
(full source: git://anongit.freedesktop.org/evtest)
static int query_device(const char *device, const struct
query_mode
*query_mode
{
int fd;
int r;
unsigned long state[NBITS(query_mode-max)];
fd = open(device, O_RDONLY);
if (fd 0) {
perror(open);
return EXIT_FAILURE;
}
memset(state, 0, sizeof(state));
r = ioctl(fd, query_mode-rq, state);
close(fd);
if (r == -1) {
perror(ioctl);
return EXIT_FAILURE;
}
if (test_bit(keycode, state))
return 10; /* different from EXIT_FAILURE */
else
return 0;
}
paul
Gonzalo
On Thu, Jan 24, 2013 at 12:16 PM, Martin Langhoff
martin.langh...@gmail.com
wrote:
On Thu, Jan 24, 2013 at 10:13 AM, Paul Fox p...@laptop.org
wrote:
i believe sugar already has code to detect the two modes,
since
that's how it knows whether to present the OSK or not.
Yep. Ajay, I think Write shows you the way :-)
m
--
martin.langh...@gmail.com
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
-
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On 2013-01-28, at 19:16, Paul Fox p...@laptop.org wrote: certainly not my call, but stealing keys which have always been intended for activities to use seems like it shouldn't be done lightly. +1 - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Butiá Firmware-2
Activity Homepage: http://activities.sugarlabs.org/addon/4621 Sugar Platform: 0.86 - 0.98 Download Now: http://activities.sugarlabs.org/downloads/file/28453/butia_firmware-2.xo Release notes: -update translations -32 and 64 bits compatibility -add Gnome use: ./ButiaFirmware.py Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
I agree with Gonzalo and Gary; this is just a makeshift solution for the
time-being, so that activities like Speak, Chat, Terminal are not rendered
completely unusable in ebook-mode.
Ideally, the best solution would be to have the OSK-appearance-and
window-shrinkage on automatic and tied-together basis (without needing
any manual intervention).
On Tue, Jan 29, 2013 at 9:17 AM, Gary Martin garycmar...@googlemail.comwrote:
On 28 Jan 2013, at 18:33, Gonzalo Odiard gonz...@laptop.org wrote:
On Mon, Jan 28, 2013 at 2:50 PM, Ajay Garg a...@activitycentral.com
wrote:
On Mon, Jan 28, 2013 at 11:01 PM, Paul Fox p...@laptop.org wrote:
ajay wrote:
Hi all.
A simple solution was found :)
I hacked the KP_Prior and KP_Next keys, and now they are used for
making-window-smaller and restoring-original-window-size respectively
:)
so sugar takes over those keys? aren't those keys used by activities?
they're certainly useful in a terminal -- page up and page down.
Hmm.. Well a simple grepping showed that the Read activity is the
only activity that explicitly makes use of the KP_Home and KP_End keys;
but none seemed to make use of KP_Prior and KP_Next.
A simple grep is not good enough. Gtk already uses these keys, for
example in a textview.
I can't understand what you are trying to do. The user should press the
key to enlarge/shrink the activity window? Does not look like a good
solution.
+1
OSK behaviour should be automatic, no user intervention (other than
perhaps some manual view scrolling when there is no active focus to get
into view). If we are missing cases (and we are currently), then these are
bugs to be fixed and/or features to be landed (often GTK3 related upstream
targets, but occasionally Sugar/Activity related patches). We made great
progress in 13.1.0, hopefully we can finish off this effort ready for
13.2.0.
Regards,
--Gary
Gonzalo
paul
All thanks to
* /usr/share/X11/xkb/keycodes/evdev
* sugar/src/jarabe/view/keyhandler.py
Just one thing I noticed when I tried to have the above keys take
effect
ONLY in ebook-mode (via the evtest --query test), that when I ran
this
again and again via the suprocess module, the XO-4 behaved very
erratically. However, when I made the keys take effect irrespective
of the
test of ebook-mode, things worked cool. However, I will keep on
looking
into the reason.
Thanks a ton to all :)
On Thu, Jan 24, 2013 at 10:45 PM, Paul Fox p...@laptop.org wrote:
gonzalo wrote:
Write does not know what is the ebook switch state, that logic
is in the
osk.
Looking in the wiki and sugar code, I could not find information
about
how
read the switch,
but in ticket http://dev.laptop.org/ticket/12326 found this:
If you do:
evtest --query /dev/input/event4 EV_SW SW_TABLET_MODE; echo $?
If the xo is in ebook mode returns 10, if not, returns 0.
There are any official doc about the switches I am missing?
There are a
way
to catch a event when the switch is activated, using dbus or
something
similar?
if you open the device and read it, you'll get a stream of struct
input_event structures (/usr/include/linux/input.h) representing
opening and closing of the SW_TABLET_MODE switch. here's a C code
snippet from olpc-switchd (part of powerd):
void ebook_event()
{
struct input_event ev[1];
if (read(ebk_fd, ev, sizeof(ev)) != sizeof(ev))
die(bad read from ebook switch);
dbg(3, ebk: ev sec %d usec %d type %d code %d value %d,
ev-time.tv_sec, ev-time.tv_usec,
ev-type, ev-code, ev-value);
if (ev-type == EV_SW ev-code == SW_TABLET_MODE) {
if (ev-value)
send_event(ebookclose, round_secs(ev),
ebk_device);
else
send_event(ebookopen, round_secs(ev), ebk_device);
}
}
perhaps there's an evdev to dbus gateway of some sort, but i don't
know
about it, if so.
the evtest commandline example, above, uses an ioctl on the input
device to determine current state. here's snippet from the evtest
source:
(full source: git://anongit.freedesktop.org/evtest)
static int query_device(const char *device, const struct
query_mode
*query_mode
{
int fd;
int r;
unsigned long state[NBITS(query_mode-max)];
fd = open(device, O_RDONLY);
if (fd 0) {
perror(open);
return EXIT_FAILURE;
}
memset(state, 0, sizeof(state));
