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. ) <div class="gmail_quote">On Wed, Jan 23, 2013 at 9:32 PM, Gary Martin <<a href="mailto:garycmartin@googlemail.com" target="_blank">garycmartin@googlemail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 23 Jan 2013, at 15:29, Walter Bender <<a href="mailto:walter.bender@gmail.com">walter.bender@gmail.com</a>> wrote: > On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg <<a href="mailto:ajay@activitycentral.com">ajay@activitycentral.com</a>> 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? </div>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. <div class="im"> > 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.) </div>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). <div class="im"> >> >> 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? </div>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 <div class="HOEnZb"><div class="h5"> > >> >> 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: <a href="http://activitycentral.com" target="_blank">http://activitycentral.com</a> >> _______________________________________________ >> Sugar-devel mailing list >> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> >> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> >> > > regards. > > -walter > -- > Walter Bender > Sugar Labs > <a href="http://www.sugarlabs.org" target="_blank">http://www.sugarlabs.org</a> > _______________________________________________ > Devel mailing list > <a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a> > <a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a> _______________________________________________ Devel mailing list <a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a> <a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a> </div></div></blockquote></div> -- Regards, Ajay Garg Dextrose Developer Activity Central: <a href="http://activitycentral.com/" style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)" target="_blank">http://activitycentral.com</a>