GNOME Bugzilla – Bug 695607
When switching input methods using the keyboard shortcut and the on-screen-display becomes too long, it becomes blank and unusable
Last modified: 2013-03-14 21:43:36 UTC
Created attachment 238556 [details] switching-input-methods-osd.png Left screen shot: ================= 7 input methods, just fits. (Number of letters in the short name of the input method seems to be limited to 3 unfortunately. The glyphs for the lower indices 1 and 2 for the two Japanese input methods in that list are clipped at the top). Right screen shot: =================== One more input method added. The on screen display which pops up when changing input methods is empty now. There is an arrow on the right side, sometimes an arrow on the left side appears as well when some input method in the middle is selected, but one never sees anything, it stays empty.
Rui, I think we should try to get this fixed for 3.8; looks pretty bad; and 7 is getting almost to a realistic number of input sources that one might have configured simultaneously.
I can't reproduce. The scroll bars work for me.
Could it be that Mike is testing in a VM?
(In reply to comment #2) Jasper> I can't reproduce. The scroll bars work for me. Scroll bars? You mean the small triangles at the left and the right side? And is the on screen display not blank for you?
Created attachment 238765 [details] Screenshot As the screenshot shows, it works fine for me.
Maybe it is a question of screen resolution ? Mike whats yours ?
Indeed, it works ok for me as well, I have to add 8 input sources before the scrolling starts, but it works fine then. Or maybe font or font size is relevant - I tried large text, it still worked fine.
(In reply to comment #6) > Maybe it is a question of screen resolution ? Mike whats yours ? 1024x768
I can reproduce it. My screen resolution is 1280x1024. However, like Mike I'm running in a VM. Could this be a driver issue?
Rui says it looks like a driver issue because the VM uses software rendering. He says it could be something mesa’s llvmpipe. So mabe I should open a bug against mesa instead?
Ayax says: <ajax> llvmpipe's rendering limits are only 2k wide i think, if clutter's creating a texture wider than that then it's not surprising (and not a mesa bug)
Created attachment 238906 [details] [review] st-scroll-view-fade: Don't use return in the shader Returing from main() makes llvmpipe unhappy (produces black output color), so rework the logic to avoid the return.
Btw. this bug affects all scroll areas where we use fade (app picker, message tray banners with scrollbars, chats ...)
Review of attachment 238906 [details] [review]: Can you please use spaces, not tabs, for indentation? And can you add a link to an upstream llvmpipe bug for this?
(In reply to comment #14) > Review of attachment 238906 [details] [review]: > > Can you please use spaces, not tabs, for indentation? Huh? Sorry this happens when you work inside a VM with nothing configured ...
Created attachment 238936 [details] [review] st-scroll-view-fade: Don't use return in the shader Returing from main() makes llvmpipe unhappy (produces black output color), so rework the logic to avoid the return. --- Fixed indentation and added a comment with a bug reference.
Review of attachment 238936 [details] [review]: OK.
Attachment 238936 [details] pushed as 45fc7ec - st-scroll-view-fade: Don't use return in the shader