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

[Ajay Garg]

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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130124/4b49e77b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Speak_screenshot.png
Type: image/png
Size: 56378 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130124/4b49e77b/attachment-0001.png>