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

[Walter Bender]

On Thu, Jan 24, 2013 at 3:22 AM, Ajay Garg <ajay at 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 <garycmartin at googlemail.com>
> wrote:
>>
>> 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
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>
>
>
>
> --
> Regards,
>
> Ajay Garg
> Dextrose Developer
> Activity Central: http://activitycentral.com



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org