Hacking onto the "appearing" and "hiding" of OSK

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Hacking onto the "appearing" and "hiding" of OSK

Ajay Garg-2
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 have tested the re-sizing the windows; however, to make the fix  work everywhere, I was thinking of the following algorithm ::

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
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Walter Bender-4
On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg <[hidden email]> 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
> [hidden email]
> http://lists.sugarlabs.org/listinfo/sugar-devel
>

regards.

-walter
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Gary Martin-2
On 23 Jan 2013, at 15:29, Walter Bender <[hidden email]> wrote:

> On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg <[hidden email]> 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
>> [hidden email]
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
> regards.
>
> -walter
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> _______________________________________________
> Devel mailing list
> [hidden email]
> http://lists.laptop.org/listinfo/devel

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Ajay Garg-2
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 :)

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).


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 <[hidden email]> wrote:
On 23 Jan 2013, at 15:29, Walter Bender <[hidden email]> wrote:

> On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg <[hidden email]> 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
>> [hidden email]
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
> regards.
>
> -walter
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> _______________________________________________
> Devel mailing list
> [hidden email]
> http://lists.laptop.org/listinfo/devel

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel



--
Regards,

Ajay Garg

Dextrose Developer
Activity Central: http://activitycentral.com
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel

Speak_screenshot.png (75K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Walter Bender-4
On Thu, Jan 24, 2013 at 3:22 AM, Ajay Garg <[hidden email]> 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 <[hidden email]>
> wrote:
>>
>> On 23 Jan 2013, at 15:29, Walter Bender <[hidden email]> wrote:
>>
>> > On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg <[hidden email]>
>> > 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
>> >> [hidden email]
>> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>> >>
>> >
>> > regards.
>> >
>> > -walter
>> > --
>> > Walter Bender
>> > Sugar Labs
>> > http://www.sugarlabs.org
>> > _______________________________________________
>> > Devel mailing list
>> > [hidden email]
>> > http://lists.laptop.org/listinfo/devel
>>
>> _______________________________________________
>> Devel mailing list
>> [hidden email]
>> http://lists.laptop.org/listinfo/devel
>
>
>
>
> --
> Regards,
>
> Ajay Garg
> Dextrose Developer
> Activity Central: http://activitycentral.com



--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Ajay Garg-2


On Thu, Jan 24, 2013 at 5:50 PM, Walter Bender <[hidden email]> wrote:
On Thu, Jan 24, 2013 at 3:22 AM, Ajay Garg <[hidden email]> 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 <[hidden email]>
> wrote:
>>
>> On 23 Jan 2013, at 15:29, Walter Bender <[hidden email]> wrote:
>>
>> > On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg <[hidden email]>
>> > 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
>> >> [hidden email]
>> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>> >>
>> >
>> > regards.
>> >
>> > -walter
>> > --
>> > Walter Bender
>> > Sugar Labs
>> > http://www.sugarlabs.org
>> > _______________________________________________
>> > Devel mailing list
>> > [hidden email]
>> > http://lists.laptop.org/listinfo/devel
>>
>> _______________________________________________
>> Devel mailing list
>> [hidden email]
>> http://lists.laptop.org/listinfo/devel
>
>
>


 
>
> --
> Regards,
>
> Ajay Garg
> Dextrose Developer
> Activity Central: http://activitycentral.com



--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel



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?



Regards,

Ajay Garg

Dextrose Developer
Activity Central: http://activitycentral.com
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Gonzalo Odiard-3
> 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
[hidden email]
http://lists.laptop.org/listinfo/devel



_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Ajay Garg-2


On Thu, Jan 24, 2013 at 6:45 PM, Gonzalo Odiard <[hidden email]> 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
[hidden email]
http://lists.laptop.org/listinfo/devel




--
Regards,

Ajay Garg

Dextrose Developer
Activity Central: http://activitycentral.com
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Ajay Garg-2


On Thu, Jan 24, 2013 at 7:04 PM, Ajay Garg <[hidden email]> wrote:


On Thu, Jan 24, 2013 at 6:45 PM, Gonzalo Odiard <[hidden email]> 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,

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
[hidden email]
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
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Gonzalo Odiard-3
....
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
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Ajay Garg-2


On Thu, Jan 24, 2013 at 7:36 PM, Gonzalo Odiard <[hidden email]> 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
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Ajay Garg-2


On Thu, Jan 24, 2013 at 7:37 PM, Ajay Garg <[hidden email]> wrote:


On Thu, Jan 24, 2013 at 7:36 PM, Gonzalo Odiard <[hidden email]> 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 :(


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
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Jerry Vonau-2


On 24 January 2013 08:11, Ajay Garg <[hidden email]> wrote:


On Thu, Jan 24, 2013 at 7:37 PM, Ajay Garg <[hidden email]> wrote:


On Thu, Jan 24, 2013 at 7:36 PM, Gonzalo Odiard <[hidden email]> 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 :(


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
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Ajay Garg-2


On Thu, Jan 24, 2013 at 8:20 PM, Jerry Vonau <[hidden email]> wrote:


On 24 January 2013 08:11, Ajay Garg <[hidden email]> wrote:


On Thu, Jan 24, 2013 at 7:37 PM, Ajay Garg <[hidden email]> wrote:


On Thu, Jan 24, 2013 at 7:36 PM, Gonzalo Odiard <[hidden email]> 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 :(


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
[hidden email]
http://lists.laptop.org/listinfo/devel




--
Regards,

Ajay Garg

Dextrose Developer
Activity Central: http://activitycentral.com
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Paul Fox-2
In reply to this post by Jerry Vonau-2
jerry wrote:
 > On 24 January 2013 08:11, Ajay Garg <[hidden email]> wrote:
 >
 > >
 > >
 > > On Thu, Jan 24, 2013 at 7:37 PM, Ajay Garg <[hidden email]>wrote:
 > >
 > >>
 > >>
 > >> On Thu, Jan 24, 2013 at 7:36 PM, Gonzalo Odiard <[hidden email]>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 :(
 > >>
 > >
 > >
 > > 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
 > [hidden email]
 > http://lists.sugarlabs.org/listinfo/sugar-devel

=---------------------
 paul fox, [hidden email]
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Martin Langhoff
On Thu, Jan 24, 2013 at 10:13 AM, Paul Fox <[hidden email]> 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
--
 [hidden email]
 [hidden email] -- 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
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Ajay Garg-2


On Thu, Jan 24, 2013 at 8:46 PM, Martin Langhoff <[hidden email]> wrote:
On Thu, Jan 24, 2013 at 10:13 AM, Paul Fox <[hidden email]> 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
--
 [hidden email]
 [hidden email] -- 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
[hidden email]
http://lists.laptop.org/listinfo/devel



--
Regards,

Ajay Garg

Dextrose Developer
Activity Central: http://activitycentral.com
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Gonzalo Odiard-3
In reply to this post by Martin Langhoff
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 <[hidden email]> wrote:
On Thu, Jan 24, 2013 at 10:13 AM, Paul Fox <[hidden email]> 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
--
 [hidden email]
 [hidden email] -- 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
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Gonzalo Odiard-3

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?



looks outdated.... 

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

Martin Langhoff
In reply to this post by Gonzalo Odiard-3
On Thu, Jan 24, 2013 at 12:02 PM, Gonzalo Odiard <[hidden email]> 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
--
 [hidden email]
 [hidden email] -- 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
[hidden email]
http://lists.laptop.org/listinfo/devel
12