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

Ajay Garg ajay at activitycentral.com
Thu Jan 24 07:55:48 EST 2013 

On Thu, Jan 24, 2013 at 5:50 PM, Walter Bender <walter.bender at gmail.com>wrote:

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

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 <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
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20130124/39ad12fb/attachment.html>

More information about the Devel mailing list