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

[Gary Martin]

On 23 Jan 2013, at 15:29, Walter Bender <walter.bender at gmail.com> wrote:

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