Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
Hi all. Just wanted to know that whether the signals used in the Write activity 'size-allocate', 'request-clear-area', 'unset-clear-area', are usable anywhere else too? I can see that these signals are being listened by class DocumentView(Abi.Widget); however, the source of this signals is unknown (or at least inconspicuous). Is Abi.Widget the source of these signals? If yes, that would mean that these signals cannot be used anywhere else on a generic basis, right? On Tue, Jan 29, 2013 at 6:10 PM, Gonzalo Odiard gonz...@laptop.org wrote: On Tue, Jan 29, 2013 at 2:17 AM, Ajay Garg a...@activitycentral.comwrote: 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. In my opinion, in this case, your hack, is exposed to the user, in a way that is worst than do not have a solution at all. In fact we spent a lot of time trying to do terminal work with osk (right now, if the cursor is behind the osk, the text area is resized and scrolled), but need more work. Be prepared to invest time to do it right, a quick hack will not be a good solution. Another problem using the terminal with the osk you will find, is the lack of auto-completion and a few keys useful in the terminal but not in normal use. May be Speak can be best solved, if you move the text input to the top of the canvas, like we did in Record activity. Chat is a little more difficult, you can move the input to the top, but the history will be hidden. (Btw, I don't know why all the chat interfaces show the history from bottom to top instead of top to bottom) Anyway, these are suggestions, should be better have a agreement with the Design Team, Gary Manuq. Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
Hi Ajay,
On 29 Jan 2013, at 05:17, Ajay Garg a...@activitycentral.com wrote:
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).
FWIW, I'm still -1 on the window-shrinkage approach.
Most activities will handle this badly, some not at all. Solutions: Allowing
the view to auto scroll to the input area (mainly a GTK3 and Sugar task,
significant amount of work already completed in 13.1.0); making sure the OSK is
hidden when not needed (e.g. Activity should make sure to defocus input widgets
when not essential, with auto refocus if physical keyboard is used and only one
text input widget target as in Speak/Chat); Some Activity layout re-designs to
optimise canvas for when OSK is visible (Speak/Chat are a good specific
Activity cases for this).
Regards,
--Gary
On Tue, Jan 29, 2013 at 9:17 AM, Gary Martin garycmar...@googlemail.com
wrote:
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
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Tue, Jan 29, 2013 at 2:17 AM, Ajay Garg a...@activitycentral.com wrote: 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. In my opinion, in this case, your hack, is exposed to the user, in a way that is worst than do not have a solution at all. In fact we spent a lot of time trying to do terminal work with osk (right now, if the cursor is behind the osk, the text area is resized and scrolled), but need more work. Be prepared to invest time to do it right, a quick hack will not be a good solution. Another problem using the terminal with the osk you will find, is the lack of auto-completion and a few keys useful in the terminal but not in normal use. May be Speak can be best solved, if you move the text input to the top of the canvas, like we did in Record activity. Chat is a little more difficult, you can move the input to the top, but the history will be hidden. (Btw, I don't know why all the chat interfaces show the history from bottom to top instead of top to bottom) Anyway, these are suggestions, should be better have a agreement with the Design Team, Gary Manuq. Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/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
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
--
Regards,
Ajay Garg
Dextrose Developer
Activity Central: http://activitycentral.com
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/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
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
--
Regards,
Ajay Garg
Dextrose Developer
Activity Central: http://activitycentral.com
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/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
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
--
Regards,
Ajay Garg
Dextrose Developer
Activity
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
--
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 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));
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
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));
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Thu, Jan 24, 2013 at 3:22 AM, Ajay Garg a...@activitycentral.com wrote: Thanks Walter and Gary for your replies. Well, what I am trying to achieve is, is just a simple and consistent (fixed) behaviour across every activity - make the window-size smaller. This serves two advantages :: * Works everywhere :) * Is consistent across everywhere :) I applaud these goals. Please find attached a sample screenshot of the Speak activity; the window has been resized to 0.7 of the original size (the screenshot doesn't show a keyboard yet, as it was done on sugar-build). Question: Do all activities behave properly when the screen is scaled that way? (I don't know that all activities are paying attention to resizing events. One quick way to check is to look at what happens when activities are rotated.) If the above seems ok, then all that is needed is a way to figure out instances when the OSK appears, and when it disappears, so that the window resizing can be done at those strategic points. ( P.S. :: I see that exporting GTK_IM_MODULE=Maliit is all that is required to start using the Maliit OSK, but I could not find any way to hack onto every appearence/disappearance of the OSK. ) On Wed, Jan 23, 2013 at 9:32 PM, Gary Martin garycmar...@googlemail.com wrote: On 23 Jan 2013, at 15:29, Walter Bender walter.ben...@gmail.com wrote: On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg a...@activitycentral.com wrote: Hi all. I wish to fix the bug, where some activities (Chat, Terminal, Speak for instance) are rendered unusable in the ebook-mode, due to the OSK covering the area of text-input. I have figured out a generic working solution for this - the idea is to minimize the activity windows when the OSK appears, and move back to the normal size when the OSK disappears. I thought we had a different approach under development: to scroll the window up in the case of the text view being occluded by the OSK? Yes, there are patches in GTK3 and Sugar for this, though with some issues still needing worked through. One activity that we managed to push hard to get polished was Write, it needed to be a special case as it doesn't use normal gtk widgets. My (rough) understanding of the implementation is that GTK first looks for a scrolled view and tries to scroll it so that the cursor/focus rect is kept in view [1], if no scrolled view is found it scrolls the canvas [2]. [1] the Write behaviour here is not ideal as the abiword widget implementation for the text area didn't allow for extra padding at the bottom of the view, so the text being edited is hard up next to the OSK rather than with some extra space so the text selection handles stay visible. [2] I think there were patches in GTK3 Sugar so that the activity canvas area was automatically placed in a scroll view, so the toolbars are guaranteed to stay in view, but not sure if this landed. This should be doable for activities that have scrolling windows, such as terminal and chat. Speak, which doesn't scroll could be refactored to put the textview on the top instead of the bottom of the screen. (I suspect that whatever solution we have will involve some intervention in some activities.) Yes some intervention in activities will still be needed, and the first thing to do if you want any of this auto scrolling support is make sure your activity is ported to GTK3! ;) FOr activities like Speak I'd posted mockup images to a previous mail list thread showing how moving the text input area to the top of the UI would work well (the eyes will just peek over the top of the keyboard and the OSK can be hidden when the text is submitted for speaking). I have tested the re-sizing the windows; however, to make the fix work everywhere, I was thinking of the following algorithm :: What does resizing the window do? What other activities have you tested it on? Some activities will become quite unusable if auto shrunk, scrolling I think is better, we're lucky if the original developer planned for landscape and portrait aspect ratios... Regards, --Gary a) Just before/after the OSK appears, make the current window smaller. b) Just after/before the OSK disappears, revert the current window to its original size (if not already). This requires a way to know when and how the appeareance/disappearance of the OSK is triggered. How can this be done? I am sure there must be some gobject-signal for this - I just can't seem to figure it out by manually browsing the code, since I don't personally have a XO4-Touch with me :-( Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel regards. -walter
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Thu, Jan 24, 2013 at 5:50 PM, Walter Bender walter.ben...@gmail.comwrote: On Thu, Jan 24, 2013 at 3:22 AM, Ajay Garg a...@activitycentral.com wrote: Thanks Walter and Gary for your replies. Well, what I am trying to achieve is, is just a simple and consistent (fixed) behaviour across every activity - make the window-size smaller. This serves two advantages :: * Works everywhere :) * Is consistent across everywhere :) I applaud these goals. Thanks :) Please find attached a sample screenshot of the Speak activity; the window has been resized to 0.7 of the original size (the screenshot doesn't show a keyboard yet, as it was done on sugar-build). Question: Do all activities behave properly when the screen is scaled that way? (I don't know that all activities are paying attention to resizing events. One quick way to check is to look at what happens when activities are rotated.) I will be receiving my XO-4 Touch in a couple of days; will answer this question then, after testing it in real-time :) If the above seems ok, then all that is needed is a way to figure out instances when the OSK appears, and when it disappears, so that the window resizing can be done at those strategic points. ( P.S. :: I see that exporting GTK_IM_MODULE=Maliit is all that is required to start using the Maliit OSK, but I could not find any way to hack onto every appearence/disappearance of the OSK. ) On Wed, Jan 23, 2013 at 9:32 PM, Gary Martin garycmar...@googlemail.com wrote: On 23 Jan 2013, at 15:29, Walter Bender walter.ben...@gmail.com wrote: On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg a...@activitycentral.com wrote: Hi all. I wish to fix the bug, where some activities (Chat, Terminal, Speak for instance) are rendered unusable in the ebook-mode, due to the OSK covering the area of text-input. I have figured out a generic working solution for this - the idea is to minimize the activity windows when the OSK appears, and move back to the normal size when the OSK disappears. I thought we had a different approach under development: to scroll the window up in the case of the text view being occluded by the OSK? Yes, there are patches in GTK3 and Sugar for this, though with some issues still needing worked through. One activity that we managed to push hard to get polished was Write, it needed to be a special case as it doesn't use normal gtk widgets. My (rough) understanding of the implementation is that GTK first looks for a scrolled view and tries to scroll it so that the cursor/focus rect is kept in view [1], if no scrolled view is found it scrolls the canvas [2]. [1] the Write behaviour here is not ideal as the abiword widget implementation for the text area didn't allow for extra padding at the bottom of the view, so the text being edited is hard up next to the OSK rather than with some extra space so the text selection handles stay visible. [2] I think there were patches in GTK3 Sugar so that the activity canvas area was automatically placed in a scroll view, so the toolbars are guaranteed to stay in view, but not sure if this landed. This should be doable for activities that have scrolling windows, such as terminal and chat. Speak, which doesn't scroll could be refactored to put the textview on the top instead of the bottom of the screen. (I suspect that whatever solution we have will involve some intervention in some activities.) Yes some intervention in activities will still be needed, and the first thing to do if you want any of this auto scrolling support is make sure your activity is ported to GTK3! ;) FOr activities like Speak I'd posted mockup images to a previous mail list thread showing how moving the text input area to the top of the UI would work well (the eyes will just peek over the top of the keyboard and the OSK can be hidden when the text is submitted for speaking). I have tested the re-sizing the windows; however, to make the fix work everywhere, I was thinking of the following algorithm :: What does resizing the window do? What other activities have you tested it on? Some activities will become quite unusable if auto shrunk, scrolling I think is better, we're lucky if the original developer planned for landscape and portrait aspect ratios... Regards, --Gary a) Just before/after the OSK appears, make the current window smaller. b) Just after/before the OSK disappears, revert the current window to its original size (if not already). This requires a way to know when and how the appeareance/disappearance of the OSK is triggered. How can this be done? I am sure there must be some gobject-signal for this - I just can't seem to figure it out by manually
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
Please find attached a sample screenshot of the Speak activity; the window has been resized to 0.7 of the original size (the screenshot doesn't show a keyboard yet, as it was done on sugar-build). Question: Do all activities behave properly when the screen is scaled that way? (I don't know that all activities are paying attention to resizing events. One quick way to check is to look at what happens when activities are rotated.) I will be receiving my XO-4 Touch in a couple of days; will answer this question then, after testing it in real-time :) XO-4 does not support rotate the screen yet. You should try with other models. Just figured out one thing via Nitika's XO-4-Touch (thanks to Nitika for bearing my brunt of the testing-questions !!), that pressing all 4 game-keys at once, does toggle the appearance of the OSK !! So, I guess, we DO have a point, wherein we can hack resizing of the window. So, now I have another question :: Where is the code for handling game keys handled (as far as appearance and disappearance of the OSK is concerned) ? In Firmware? In Sugar? Elsewhere? The keyboard appear because you pressed a key (you don't need press the 4 at once, any key will show it) Detecting osk show/hide. is more complicate than should be, in my point of view. Probably, because the idea behind this is the osk should appear and hide in a automatic way based in the widgets needs. I think you should check the class DocumentView in widgets.py in Write activity, to see how the signals are used. Carlos Garnacho worked on this. Gonzalo Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Thu, Jan 24, 2013 at 6:45 PM, Gonzalo Odiard gonz...@laptop.org wrote: Please find attached a sample screenshot of the Speak activity; the window has been resized to 0.7 of the original size (the screenshot doesn't show a keyboard yet, as it was done on sugar-build). Question: Do all activities behave properly when the screen is scaled that way? (I don't know that all activities are paying attention to resizing events. One quick way to check is to look at what happens when activities are rotated.) I will be receiving my XO-4 Touch in a couple of days; will answer this question then, after testing it in real-time :) XO-4 does not support rotate the screen yet. You should try with other models. Ok, thanks for the info :) Just figured out one thing via Nitika's XO-4-Touch (thanks to Nitika for bearing my brunt of the testing-questions !!), that pressing all 4 game-keys at once, does toggle the appearance of the OSK !! So, I guess, we DO have a point, wherein we can hack resizing of the window. So, now I have another question :: Where is the code for handling game keys handled (as far as appearance and disappearance of the OSK is concerned) ? In Firmware? In Sugar? Elsewhere? The keyboard appear because you pressed a key (you don't need press the 4 at once, any key will show it) Detecting osk show/hide. is more complicate than should be, in my point of view. Probably, because the idea behind this is the osk should appear and hide in a automatic way based in the widgets needs. I think you should check the class DocumentView in widgets.py in Write activity, to see how the signals are used. Carlos Garnacho worked on this. Ahh.. that's a nice pointer Gonzalo :) It seems that only size-allocate and request-clear-area are the signals to be considered (not sure though; again, can only verify after a couple of days). If these signals are in fact emitted when the OSK appears/disappears by pressing a game key, I think we should be done. We would have found a hack :) Keeping fingers crossed, and waiting eagerly for my XO-4-Touch to arrive. Gonzalo Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Thu, Jan 24, 2013 at 7:04 PM, Ajay Garg a...@activitycentral.com wrote: On Thu, Jan 24, 2013 at 6:45 PM, Gonzalo Odiard gonz...@laptop.orgwrote: Please find attached a sample screenshot of the Speak activity; the window has been resized to 0.7 of the original size (the screenshot doesn't show a keyboard yet, as it was done on sugar-build). Question: Do all activities behave properly when the screen is scaled that way? (I don't know that all activities are paying attention to resizing events. One quick way to check is to look at what happens when activities are rotated.) I will be receiving my XO-4 Touch in a couple of days; will answer this question then, after testing it in real-time :) XO-4 does not support rotate the screen yet. You should try with other models. Ok, thanks for the info :) Just figured out one thing via Nitika's XO-4-Touch (thanks to Nitika for bearing my brunt of the testing-questions !!), that pressing all 4 game-keys at once, does toggle the appearance of the OSK !! So, I guess, we DO have a point, wherein we can hack resizing of the window. So, now I have another question :: Where is the code for handling game keys handled (as far as appearance and disappearance of the OSK is concerned) ? In Firmware? In Sugar? Elsewhere? The keyboard appear because you pressed a key (you don't need press the 4 at once, any key will show it) Detecting osk show/hide. is more complicate than should be, in my point of view. Probably, because the idea behind this is the osk should appear and hide in a automatic way based in the widgets needs. I think you should check the class DocumentView in widgets.py in Write activity, to see how the signals are used. Carlos Garnacho worked on this. Ahh.. that's a nice pointer Gonzalo :) It seems that only size-allocate and request-clear-area are the signals to be considered (not sure though; again, can only verify after a couple of days). If these signals are in fact emitted when the OSK appears/disappears by pressing a game key, I think we should be done. We would have found a hack :) Keeping fingers crossed, and waiting eagerly for my XO-4-Touch to arrive. Gonzalo, another thing Nitika and me found, are the following :: a) Ensure that the XO is in normal-mode, and no activity is turned on. b) Turn to ebook-mode. c) Open Speak activity. d) OSK appears automatically this time. e) Now, pressing the game-key does not cause the OSK to go away :-\ It is only when the keyboard key is pressed, does the OSK disappear. f) If the game-key is pressed again, the OSK appears. Gist :: Game-key works fine and consistently, when the OSK is required to be made appeared. BUT, it does NOT WORK, if the OSK has been launched automatically. So, it seems that just hacking onto the game-key won't help :( Gonzalo Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com -- Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
So, it seems that just hacking onto the game-key won't help :( No. Will not work, because the osk will appear if you touch over a input widget. The game keys are not the expected way to show the osk. Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Thu, Jan 24, 2013 at 7:36 PM, Gonzalo Odiard gonz...@laptop.org wrote: So, it seems that just hacking onto the game-key won't help :( No. Will not work, because the osk will appear if you touch over a input widget. The game keys are not the expected way to show the osk. Hmm.. which brings us back to square one :( Gonzalo -- Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Thu, Jan 24, 2013 at 7:37 PM, Ajay Garg a...@activitycentral.com wrote: On Thu, Jan 24, 2013 at 7:36 PM, Gonzalo Odiard gonz...@laptop.orgwrote: So, it seems that just hacking onto the game-key won't help :( No. Will not work, because the osk will appear if you touch over a input widget. The game keys are not the expected way to show the osk. Hmm.. which brings us back to square one :( Let's try another way :P Is there a way, so that we may know whether we are in ebook-mode, or normal-mode? If yes, we can at least make the windows smaller for newly launched activity-windows. Gonzalo -- Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com -- Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On 24 January 2013 08:11, Ajay Garg a...@activitycentral.com wrote: On Thu, Jan 24, 2013 at 7:37 PM, Ajay Garg a...@activitycentral.comwrote: On Thu, Jan 24, 2013 at 7:36 PM, Gonzalo Odiard gonz...@laptop.orgwrote: So, it seems that just hacking onto the game-key won't help :( No. Will not work, because the osk will appear if you touch over a input widget. The game keys are not the expected way to show the osk. Hmm.. which brings us back to square one :( Let's try another way :P Is there a way, so that we may know whether we are in ebook-mode, or normal-mode? Yes, there is a ebook switch event: Jan 24 01:14:28 xo-1e-89-0d kernel: OLPC XO-1.75 lid and ebook switches Jan 24 01:14:28 xo-1e-89-0d kernel: input: OLPC lid switch as /devices/virtual/input/input3 Jan 24 01:14:28 xo-1e-89-0d kernel: input: OLPC ebook switch as /devices/virtual/input/input4 Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: starting olpc-kbdshim-udev version 29 Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 4: found touchscreen (zForce touchscreen) /dev/input/event8 (18:00:00) Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 6: found keyboard (AT Translated Set 2 keyboard) /dev/input/event5 (11:01:01) Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 7: found touchpad (FSPPS/2 Sentelic FingerSensingPad) /dev/input/event9 (11:02:0f) Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 8: found ebook switch Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Thu, Jan 24, 2013 at 8:20 PM, Jerry Vonau je...@laptop.org.au wrote: On 24 January 2013 08:11, Ajay Garg a...@activitycentral.com wrote: On Thu, Jan 24, 2013 at 7:37 PM, Ajay Garg a...@activitycentral.comwrote: On Thu, Jan 24, 2013 at 7:36 PM, Gonzalo Odiard gonz...@laptop.orgwrote: So, it seems that just hacking onto the game-key won't help :( No. Will not work, because the osk will appear if you touch over a input widget. The game keys are not the expected way to show the osk. Hmm.. which brings us back to square one :( Let's try another way :P Is there a way, so that we may know whether we are in ebook-mode, or normal-mode? Yes, there is a ebook switch event: Jan 24 01:14:28 xo-1e-89-0d kernel: OLPC XO-1.75 lid and ebook switches Jan 24 01:14:28 xo-1e-89-0d kernel: input: OLPC lid switch as /devices/virtual/input/input3 Jan 24 01:14:28 xo-1e-89-0d kernel: input: OLPC ebook switch as /devices/virtual/input/input4 Great !! Now a good weekend exercise, to bring this message from kernel to user space :) Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: starting olpc-kbdshim-udev version 29 Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 4: found touchscreen (zForce touchscreen) /dev/input/event8 (18:00:00) Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 6: found keyboard (AT Translated Set 2 keyboard) /dev/input/event5 (11:01:01) Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 7: found touchpad (FSPPS/2 Sentelic FingerSensingPad) /dev/input/event9 (11:02:0f) Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 8: found ebook switch Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
jerry wrote: On 24 January 2013 08:11, Ajay Garg a...@activitycentral.com wrote: On Thu, Jan 24, 2013 at 7:37 PM, Ajay Garg a...@activitycentral.comwrote: On Thu, Jan 24, 2013 at 7:36 PM, Gonzalo Odiard gonz...@laptop.orgwrote: So, it seems that just hacking onto the game-key won't help :( No. Will not work, because the osk will appear if you touch over a input widget. The game keys are not the expected way to show the osk. Hmm.. which brings us back to square one :( Let's try another way :P Is there a way, so that we may know whether we are in ebook-mode, or normal-mode? Yes, there is a ebook switch event: i believe sugar already has code to detect the two modes, since that's how it knows whether to present the OSK or not. paul Jan 24 01:14:28 xo-1e-89-0d kernel: OLPC XO-1.75 lid and ebook switches Jan 24 01:14:28 xo-1e-89-0d kernel: input: OLPC lid switch as /devices/virtual/input/input3 Jan 24 01:14:28 xo-1e-89-0d kernel: input: OLPC ebook switch as /devices/virtual/input/input4 Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: starting olpc-kbdshim-udev version 29 Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 4: found touchscreen (zForce touchscreen) /dev/input/event8 (18:00:00) Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 6: found keyboard (AT Translated Set 2 keyboard) /dev/input/event5 (11:01:01) Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 7: found touchpad (FSPPS/2 Sentelic FingerSensingPad) /dev/input/event9 (11:02:0f) Jan 24 01:14:49 xo-1e-89-0d olpc-kbdshim-udev[484]: olpc-kbdshim-udev: fd 8: found ebook switch Jerry part 2 text/plain 153 ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Thu, Jan 24, 2013 at 8:46 PM, Martin Langhoff martin.langh...@gmail.comwrote: 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 :-) Great.. Thanks !!! So the candle lights again in my heart; again waiting eagerly for my XO-4-Touch to arrive in a couple of days :) 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
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? 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
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? http://wiki.laptop.org/go/Power_management#Ebook_sense_switch looks outdated ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Thu, Jan 24, 2013 at 12:02 PM, Gonzalo Odiard gonz...@laptop.org wrote: Write does not know what is the ebook switch state, that logic is in the osk. And that's correct. ebook mode is one reason to show the OSK. There are other reasons -- for example, - accesibility - typing in a different language from what your physical keyboard has That's why I suggest to Ajay to do as Write does :-) 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
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
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg a...@activitycentral.com wrote: Hi all. I wish to fix the bug, where some activities (Chat, Terminal, Speak for instance) are rendered unusable in the ebook-mode, due to the OSK covering the area of text-input. I have figured out a generic working solution for this - the idea is to minimize the activity windows when the OSK appears, and move back to the normal size when the OSK disappears. I thought we had a different approach under development: to scroll the window up in the case of the text view being occluded by the OSK? This should be doable for activities that have scrolling windows, such as terminal and chat. Speak, which doesn't scroll could be refactored to put the textview on the top instead of the bottom of the screen. (I suspect that whatever solution we have will involve some intervention in some activities.) I have tested the re-sizing the windows; however, to make the fix work everywhere, I was thinking of the following algorithm :: What does resizing the window do? What other activities have you tested it on? a) Just before/after the OSK appears, make the current window smaller. b) Just after/before the OSK disappears, revert the current window to its original size (if not already). This requires a way to know when and how the appeareance/disappearance of the OSK is triggered. How can this be done? I am sure there must be some gobject-signal for this - I just can't seem to figure it out by manually browsing the code, since I don't personally have a XO4-Touch with me :-( Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK
On 23 Jan 2013, at 15:29, Walter Bender walter.ben...@gmail.com wrote: On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg a...@activitycentral.com wrote: Hi all. I wish to fix the bug, where some activities (Chat, Terminal, Speak for instance) are rendered unusable in the ebook-mode, due to the OSK covering the area of text-input. I have figured out a generic working solution for this - the idea is to minimize the activity windows when the OSK appears, and move back to the normal size when the OSK disappears. I thought we had a different approach under development: to scroll the window up in the case of the text view being occluded by the OSK? Yes, there are patches in GTK3 and Sugar for this, though with some issues still needing worked through. One activity that we managed to push hard to get polished was Write, it needed to be a special case as it doesn't use normal gtk widgets. My (rough) understanding of the implementation is that GTK first looks for a scrolled view and tries to scroll it so that the cursor/focus rect is kept in view [1], if no scrolled view is found it scrolls the canvas [2]. [1] the Write behaviour here is not ideal as the abiword widget implementation for the text area didn't allow for extra padding at the bottom of the view, so the text being edited is hard up next to the OSK rather than with some extra space so the text selection handles stay visible. [2] I think there were patches in GTK3 Sugar so that the activity canvas area was automatically placed in a scroll view, so the toolbars are guaranteed to stay in view, but not sure if this landed. This should be doable for activities that have scrolling windows, such as terminal and chat. Speak, which doesn't scroll could be refactored to put the textview on the top instead of the bottom of the screen. (I suspect that whatever solution we have will involve some intervention in some activities.) Yes some intervention in activities will still be needed, and the first thing to do if you want any of this auto scrolling support is make sure your activity is ported to GTK3! ;) FOr activities like Speak I'd posted mockup images to a previous mail list thread showing how moving the text input area to the top of the UI would work well (the eyes will just peek over the top of the keyboard and the OSK can be hidden when the text is submitted for speaking). I have tested the re-sizing the windows; however, to make the fix work everywhere, I was thinking of the following algorithm :: What does resizing the window do? What other activities have you tested it on? Some activities will become quite unusable if auto shrunk, scrolling I think is better, we're lucky if the original developer planned for landscape and portrait aspect ratios... Regards, --Gary a) Just before/after the OSK appears, make the current window smaller. b) Just after/before the OSK disappears, revert the current window to its original size (if not already). This requires a way to know when and how the appeareance/disappearance of the OSK is triggered. How can this be done? I am sure there must be some gobject-signal for this - I just can't seem to figure it out by manually browsing the code, since I don't personally have a XO4-Touch with me :-( Regards, Ajay Garg Dextrose Developer Activity Central: http://activitycentral.com ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
