[Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK
ajay at activitycentral.com
Thu Jan 24 03:22:50 EST 2013
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>
> >> 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
> >> 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 , if no scrolled view is found it
> scrolls the canvas .
>  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
>  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...
> >> 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
> >> 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
Activity Central: http://activitycentral.com
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 56378 bytes
Desc: not available
More information about the Sugar-devel