Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 12/03/2012 03:31, Anthony Liguori wrote: On 03/11/2012 01:24 PM, François Revol wrote: GTK itself causes problems, because, it's not ported, thus not available, to all platforms QEMU can run on. It's certainly not available on Haiku at least. There is no perfect solution here. I think GTK is the best that's out there. Well as long as it's not mandatory... By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). Hmm the thing using libvte that uses /tmp to insecurely store terminal backlogs ? ;-) Yeah, I saw it on a blog, it must be true! Well it is true, just fill up your /tmp and see the backlog stop working in gnome-terminal. I did it unintentionally the other day... :P François.
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 03/12/2012 11:39 AM, François Revol wrote: On 12/03/2012 03:31, Anthony Liguori wrote: On 03/11/2012 01:24 PM, François Revol wrote: GTK itself causes problems, because, it's not ported, thus not available, to all platforms QEMU can run on. It's certainly not available on Haiku at least. There is no perfect solution here. I think GTK is the best that's out there. Well as long as it's not mandatory... By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). Hmm the thing using libvte that uses /tmp to insecurely store terminal backlogs ? ;-) Yeah, I saw it on a blog, it must be true! Well it is true, just fill up your /tmp and see the backlog stop working in gnome-terminal. I did it unintentionally the other day... :P The issue is viewing '/tmp' as insecure. Per-user TMPDIR has existed almost for a decade now. Moreover, /tmp files can be created safely using the appropriate syscalls (which VTE uses). If you're worried about securing your data and are surprised by the fact that /tmp isn't encrypted, you should be using full disk encryption because /tmp isn't the only place that needs to be worried about. Regards, Anthony Liguori François.
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
Am 27.02.2012 00:46, schrieb Anthony Liguori: I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. The two pieces of feedback I've gotten the most re: accessibility are the lack of QEMU's enablement for screen readers and the lack of configurable accelerators. Since we render our own terminal using a fixed sized font, we don't respect system font settings which means we ignore if the user has configured large print. We also don't integrate at all with screen readers which means that for blind users, the virtual consoles may as well not even exist. We also don't allow any type of configuration of accelerators. For users with limited dexterity (this is actually more common than you would think), they may use an input device that only inputs one key at a time. Holding down two keys at once is not possible for these users. These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). I'm not attempting to make a pretty desktop virtualization UI. Maybe we'll go there eventually but that's not what this series is about. This is just attempting to use a richer toolkit such that we can enable basic accessibility support. As a consequence, the UI is much more usable even for a user without accessibility requirements so it's a win-win. Also available at: https://github.com/aliguori/qemu/tree/gtk.2 --- v1 - v2 - Add internationalization support. I don't actually speak any other languages so I added a placeholder for a German translation. This can be tested with LANGUAGE=de_DE.UTF-8 qemu-system-x86_64 - Fixed the terminal size for VteTerminal widgets. I think the behavior makes sense now. - Fixed lots of issues raised in review comments (see individual patches) Known Issues: - I saw the X crash once. I think it has to do with widget sizes. I need to work harder to reproduce. - I've not recreated the reported memory leak yet. - I haven't added backwards compatibility code for older VteTerminal widgets yet. Hi Anthony, are you still working on a new version of this patch series? I suggest to commit a slightly modified version of v2 which adds the GTK UI as an optional user interface (only enabled by a configure option). This makes testing easier and allows developers to send patches which improve the new UI. As soon as the GTK UI is considered stable and usable, the default could be changed from SDL to GTK. Regards, Stefan Weil PS. Of course the committed patches should pass checkpatch.pl without errors.
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
Am 11.03.2012 19:24, schrieb François Revol: On -10/01/-28163 20:59, Stefan Weil wrote: Am 27.02.2012 00:46, schrieb Anthony Liguori: I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. [...] While I do think accessibility is important... These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. GTK itself causes problems, because, it's not ported, thus not available, to all platforms QEMU can run on. It's certainly not available on Haiku at least. Of course, SDL itself is not really a good candidate to add a11y features, due to its framebuffer-based design... By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). Hmm the thing using libvte that uses /tmp to insecurely store terminal backlogs ? ;-) [snip] As soon as the GTK UI is considered stable and usable, the default could be changed from SDL to GTK. Due to GTK not being as universally available as SDL, I'd really like not to. François. Agreed. I should have been more precise. The default could be changed from SDL to GTK when GTK is available and working (this implies not for Haiku, not for compilation environments without the necessary GTK installation, and also not for Windows as long as the GTK UI freezes QEMU). Stefan
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On -10/01/-28163 20:59, Stefan Weil wrote: Am 27.02.2012 00:46, schrieb Anthony Liguori: I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. [...] While I do think accessibility is important... These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. GTK itself causes problems, because, it's not ported, thus not available, to all platforms QEMU can run on. It's certainly not available on Haiku at least. Of course, SDL itself is not really a good candidate to add a11y features, due to its framebuffer-based design... By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). Hmm the thing using libvte that uses /tmp to insecurely store terminal backlogs ? ;-) [snip] As soon as the GTK UI is considered stable and usable, the default could be changed from SDL to GTK. Due to GTK not being as universally available as SDL, I'd really like not to. François.
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 03/11/2012 12:29 PM, Stefan Weil wrote: Hi Anthony, are you still working on a new version of this patch series? Yeah, but this is purely a free time project which is in short supply these days :-) I suggest to commit a slightly modified version of v2 which adds the GTK UI as an optional user interface (only enabled by a configure option). The big thing I have on my TODO list is understanding what's happening with resizing. I'm actually in the process of upgrading to GTK3 so I hope I'll see the issues other people are having. I'll try to get a new series out as soon as I have some free time. Regards, Anthony Liguori This makes testing easier and allows developers to send patches which improve the new UI. As soon as the GTK UI is considered stable and usable, the default could be changed from SDL to GTK. Regards, Stefan Weil PS. Of course the committed patches should pass checkpatch.pl without errors.
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 03/11/2012 01:24 PM, François Revol wrote: GTK itself causes problems, because, it's not ported, thus not available, to all platforms QEMU can run on. It's certainly not available on Haiku at least. There is no perfect solution here. I think GTK is the best that's out there. By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). Hmm the thing using libvte that uses /tmp to insecurely store terminal backlogs ? ;-) Yeah, I saw it on a blog, it must be true! Regards, Anthony Liguori As soon as the GTK UI is considered stable and usable, the default could be changed from SDL to GTK. Due to GTK not being as universally available as SDL, I'd really like not to. François.
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 2012-02-27 00:46, Anthony Liguori wrote: I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. The two pieces of feedback I've gotten the most re: accessibility are the lack of QEMU's enablement for screen readers and the lack of configurable accelerators. Since we render our own terminal using a fixed sized font, we don't respect system font settings which means we ignore if the user has configured large print. We also don't integrate at all with screen readers which means that for blind users, the virtual consoles may as well not even exist. We also don't allow any type of configuration of accelerators. For users with limited dexterity (this is actually more common than you would think), they may use an input device that only inputs one key at a time. Holding down two keys at once is not possible for these users. These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). I'm not attempting to make a pretty desktop virtualization UI. Maybe we'll go there eventually but that's not what this series is about. This is just attempting to use a richer toolkit such that we can enable basic accessibility support. As a consequence, the UI is much more usable even for a user without accessibility requirements so it's a win-win. Also available at: https://github.com/aliguori/qemu/tree/gtk.2 --- v1 - v2 - Add internationalization support. I don't actually speak any other languages so I added a placeholder for a German translation. This can be tested with LANGUAGE=de_DE.UTF-8 qemu-system-x86_64 - Fixed the terminal size for VteTerminal widgets. I think the behavior makes sense now. - Fixed lots of issues raised in review comments (see individual patches) Known Issues: - I saw the X crash once. I think it has to do with widget sizes. I need to work harder to reproduce. - I've not recreated the reported memory leak yet. - I haven't added backwards compatibility code for older VteTerminal widgets yet. Looks quite nice but still has some rough edges: - full screen doesn't work, at least here - lacking support for auto-grabbing in absolute mouse mode - unscaling (ctrl-alt-u) is lacking - window not resizable (except in broken full-screen mode) Will see if I find some time to look into this. Is this also working properly under Windows? Otherwise we probably can't deprecate SDL - or would have to provide a native Windows GUI. As we have a menu now, I would suggest to add some handy monitor commands there as well, like reset or powerdown. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 02/27/2012 02:21 AM, Jan Kiszka wrote: On 2012-02-27 00:46, Anthony Liguori wrote: I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. The two pieces of feedback I've gotten the most re: accessibility are the lack of QEMU's enablement for screen readers and the lack of configurable accelerators. Since we render our own terminal using a fixed sized font, we don't respect system font settings which means we ignore if the user has configured large print. We also don't integrate at all with screen readers which means that for blind users, the virtual consoles may as well not even exist. We also don't allow any type of configuration of accelerators. For users with limited dexterity (this is actually more common than you would think), they may use an input device that only inputs one key at a time. Holding down two keys at once is not possible for these users. These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). I'm not attempting to make a pretty desktop virtualization UI. Maybe we'll go there eventually but that's not what this series is about. This is just attempting to use a richer toolkit such that we can enable basic accessibility support. As a consequence, the UI is much more usable even for a user without accessibility requirements so it's a win-win. Also available at: https://github.com/aliguori/qemu/tree/gtk.2 --- v1 - v2 - Add internationalization support. I don't actually speak any other languages so I added a placeholder for a German translation. This can be tested with LANGUAGE=de_DE.UTF-8 qemu-system-x86_64 - Fixed the terminal size for VteTerminal widgets. I think the behavior makes sense now. - Fixed lots of issues raised in review comments (see individual patches) Known Issues: - I saw the X crash once. I think it has to do with widget sizes. I need to work harder to reproduce. - I've not recreated the reported memory leak yet. - I haven't added backwards compatibility code for older VteTerminal widgets yet. Looks quite nice but still has some rough edges: - full screen doesn't work, at least here How does it fail? It works for me. What distro are you on? - lacking support for auto-grabbing in absolute mouse mode What do you mean by auto grabbing? - unscaling (ctrl-alt-u) is lacking Since we scale by 25% up and down, I figured it wasn't strictly necessary anymore because it's very easy to zoom back to the original size. It's easy enough to add though. - window not resizable (except in broken full-screen mode) That's intentional. Will see if I find some time to look into this. Is this also working properly under Windows? Otherwise we probably can't deprecate SDL - or would have to provide a native Windows GUI. It should, but it doesn't right now most likely because of the glib event loop being broken on win32. As we have a menu now, I would suggest to add some handy monitor commands there as well, like reset or powerdown. Absolutely. I wanted to start with something very simple though first. Regards, Anthony Liguori Jan
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 2012-02-27 14:10, Anthony Liguori wrote: On 02/27/2012 02:21 AM, Jan Kiszka wrote: On 2012-02-27 00:46, Anthony Liguori wrote: I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. The two pieces of feedback I've gotten the most re: accessibility are the lack of QEMU's enablement for screen readers and the lack of configurable accelerators. Since we render our own terminal using a fixed sized font, we don't respect system font settings which means we ignore if the user has configured large print. We also don't integrate at all with screen readers which means that for blind users, the virtual consoles may as well not even exist. We also don't allow any type of configuration of accelerators. For users with limited dexterity (this is actually more common than you would think), they may use an input device that only inputs one key at a time. Holding down two keys at once is not possible for these users. These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). I'm not attempting to make a pretty desktop virtualization UI. Maybe we'll go there eventually but that's not what this series is about. This is just attempting to use a richer toolkit such that we can enable basic accessibility support. As a consequence, the UI is much more usable even for a user without accessibility requirements so it's a win-win. Also available at: https://github.com/aliguori/qemu/tree/gtk.2 --- v1 - v2 - Add internationalization support. I don't actually speak any other languages so I added a placeholder for a German translation. This can be tested with LANGUAGE=de_DE.UTF-8 qemu-system-x86_64 - Fixed the terminal size for VteTerminal widgets. I think the behavior makes sense now. - Fixed lots of issues raised in review comments (see individual patches) Known Issues: - I saw the X crash once. I think it has to do with widget sizes. I need to work harder to reproduce. - I've not recreated the reported memory leak yet. - I haven't added backwards compatibility code for older VteTerminal widgets yet. Looks quite nice but still has some rough edges: - full screen doesn't work, at least here How does it fail? The window changes to resizable mode, but remains a decorated window. It works for me. What distro are you on? OpenSUSE 11.4, gnome2. - lacking support for auto-grabbing in absolute mouse mode What do you mean by auto grabbing? That all keyboard inputs are grabbed when the mouse is in the window and you don't need to press ctrl-alt-g explicitly. And the reverse should happen when the mouse reaches the window border. Just like under SDL, give it a try. - unscaling (ctrl-alt-u) is lacking Since we scale by 25% up and down, I figured it wasn't strictly necessary anymore because it's very easy to zoom back to the original size. It's easy enough to add though. It's mandatory for usability IMHO. You find this back to 1:1 view in almost every application that supports scaling of its view, and we even have a pre-defined shortcut for it for some releases now. - window not resizable (except in broken full-screen mode) That's intentional. And a mistake IMHO. Definitely for the text consoles, but one can also argue about the guest graphic console. I think Stefano once introduced this for some Xen use case, maybe he can comment on it. BTW, VGA is the wrong term for the graphic console. Maybe there is the real front-end name available somewhere and could be used instead. Will see if I find some time to look into this. Is this also working properly under Windows? Otherwise we probably can't deprecate SDL - or would have to provide a native Windows GUI. It should, but it doesn't right now most likely because of the glib event loop being broken on win32. Sounds great. As we have a menu now, I would suggest to add some handy monitor commands there as well, like reset or powerdown. Absolutely. I wanted to start with something very simple though first. Regards, Anthony Liguori Jan Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 02/27/2012 07:26 AM, Jan Kiszka wrote: On 2012-02-27 14:10, Anthony Liguori wrote: On 02/27/2012 02:21 AM, Jan Kiszka wrote: On 2012-02-27 00:46, Anthony Liguori wrote: I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. The two pieces of feedback I've gotten the most re: accessibility are the lack of QEMU's enablement for screen readers and the lack of configurable accelerators. Since we render our own terminal using a fixed sized font, we don't respect system font settings which means we ignore if the user has configured large print. We also don't integrate at all with screen readers which means that for blind users, the virtual consoles may as well not even exist. We also don't allow any type of configuration of accelerators. For users with limited dexterity (this is actually more common than you would think), they may use an input device that only inputs one key at a time. Holding down two keys at once is not possible for these users. These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). I'm not attempting to make a pretty desktop virtualization UI. Maybe we'll go there eventually but that's not what this series is about. This is just attempting to use a richer toolkit such that we can enable basic accessibility support. As a consequence, the UI is much more usable even for a user without accessibility requirements so it's a win-win. Also available at: https://github.com/aliguori/qemu/tree/gtk.2 --- v1 - v2 - Add internationalization support. I don't actually speak any other languages so I added a placeholder for a German translation. This can be tested with LANGUAGE=de_DE.UTF-8 qemu-system-x86_64 - Fixed the terminal size for VteTerminal widgets. I think the behavior makes sense now. - Fixed lots of issues raised in review comments (see individual patches) Known Issues: - I saw the X crash once. I think it has to do with widget sizes. I need to work harder to reproduce. - I've not recreated the reported memory leak yet. - I haven't added backwards compatibility code for older VteTerminal widgets yet. Looks quite nice but still has some rough edges: - full screen doesn't work, at least here How does it fail? The window changes to resizable mode, but remains a decorated window. It works for me. What distro are you on? OpenSUSE 11.4, gnome2. Okay, I'll setup a system and test it out. - lacking support for auto-grabbing in absolute mouse mode What do you mean by auto grabbing? That all keyboard inputs are grabbed when the mouse is in the window and you don't need to press ctrl-alt-g explicitly. And the reverse should happen when the mouse reaches the window border. Just like under SDL, give it a try. Right, this was intentional. I think it's weird that a window would steal input when the mouse moves over it breaking desktop accelerators like alt tab. If you've ever alt-tab cycled through windows when QEMU is running, if you're unlucky enough to have the mouse where a QEMU window may be, the QEMU instance will steal input and prevent alt-tab from working anymore. - unscaling (ctrl-alt-u) is lacking Since we scale by 25% up and down, I figured it wasn't strictly necessary anymore because it's very easy to zoom back to the original size. It's easy enough to add though. It's mandatory for usability IMHO. You find this back to 1:1 view in almost every application that supports scaling of its view, and we even have a pre-defined shortcut for it for some releases now. I'll add it. - window not resizable (except in broken full-screen mode) That's intentional. And a mistake IMHO. Definitely for the text consoles, but one can also argue about the guest graphic console. I think Stefano once introduced this for some Xen use case, maybe he can comment on it. If we added resize, I wouldn't want to scale-to-size. I find this behavior to be more trouble than it's worth. I'd want to render the VGA screen with a black border only scaling based on the zoom settings. BTW, VGA is the wrong term for the graphic console. Maybe there is the real front-end name available somewhere and could be used instead. Any suggestions? Display? Graphics? Or were you thinking something like Cirrus VGA? Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 2012-02-27 14:33, Anthony Liguori wrote: That all keyboard inputs are grabbed when the mouse is in the window and you don't need to press ctrl-alt-g explicitly. And the reverse should happen when the mouse reaches the window border. Just like under SDL, give it a try. Right, this was intentional. I think it's weird that a window would steal input when the mouse moves over it breaking desktop accelerators like alt tab. If you've ever alt-tab cycled through windows when QEMU is running, if you're unlucky enough to have the mouse where a QEMU window may be, the QEMU instance will steal input and prevent alt-tab from working anymore. This would be a usability regression. It is very unhandy to switch between grabbed and ungrabbed, specifically for alt-tab, when working with guests vs. host windows. Look e.g. at how rdeskop works in this regard. That's why I introduced this feature to QEMU, and I would not want to see it die again with the introduction of GTK. - window not resizable (except in broken full-screen mode) That's intentional. And a mistake IMHO. Definitely for the text consoles, but one can also argue about the guest graphic console. I think Stefano once introduced this for some Xen use case, maybe he can comment on it. If we added resize, I wouldn't want to scale-to-size. I find this behavior to be more trouble than it's worth. I'd want to render the VGA screen with a black border only scaling based on the zoom settings. OK for aspect-ratio-correct scaling of the guest view from my POV. And if there is a use case for the old behavior, we could still add a switch to the menu for selecting the scaling mode. BTW, VGA is the wrong term for the graphic console. Maybe there is the real front-end name available somewhere and could be used instead. Any suggestions? Display? Graphics? Or were you thinking something like Cirrus VGA? VGA is (mostly) x86. Also, we may once have multiple guest screens, maybe even multiple types of them. So picking up some telling front-end name would likely scale best. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 02/27/2012 07:42 AM, Jan Kiszka wrote: On 2012-02-27 14:33, Anthony Liguori wrote: That all keyboard inputs are grabbed when the mouse is in the window and you don't need to press ctrl-alt-g explicitly. And the reverse should happen when the mouse reaches the window border. Just like under SDL, give it a try. Right, this was intentional. I think it's weird that a window would steal input when the mouse moves over it breaking desktop accelerators like alt tab. If you've ever alt-tab cycled through windows when QEMU is running, if you're unlucky enough to have the mouse where a QEMU window may be, the QEMU instance will steal input and prevent alt-tab from working anymore. This would be a usability regression. It is very unhandy to switch between grabbed and ungrabbed, specifically for alt-tab, when working with guests vs. host windows. Look e.g. at how rdeskop works in this regard. That's why I introduced this feature to QEMU, and I would not want to see it die again with the introduction of GTK. I'll add a Grab on Hover menu item to enable the behavior. It's a good excuse to look at gconf to store GUI preferences too. - window not resizable (except in broken full-screen mode) That's intentional. And a mistake IMHO. Definitely for the text consoles, but one can also argue about the guest graphic console. I think Stefano once introduced this for some Xen use case, maybe he can comment on it. If we added resize, I wouldn't want to scale-to-size. I find this behavior to be more trouble than it's worth. I'd want to render the VGA screen with a black border only scaling based on the zoom settings. OK for aspect-ratio-correct scaling of the guest view from my POV. And if there is a use case for the old behavior, we could still add a switch to the menu for selecting the scaling mode. Okay, I'll look into it. BTW, VGA is the wrong term for the graphic console. Maybe there is the real front-end name available somewhere and could be used instead. Any suggestions? Display? Graphics? Or were you thinking something like Cirrus VGA? VGA is (mostly) x86. Also, we may once have multiple guest screens, maybe even multiple types of them. So picking up some telling front-end name would likely scale best. Display 0? I think Monitor would be more natural but obviously that would conflict with the human monitor. Regards, Anthony Liguori Jan
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 2012-02-27 14:50, Anthony Liguori wrote: On 02/27/2012 07:42 AM, Jan Kiszka wrote: On 2012-02-27 14:33, Anthony Liguori wrote: That all keyboard inputs are grabbed when the mouse is in the window and you don't need to press ctrl-alt-g explicitly. And the reverse should happen when the mouse reaches the window border. Just like under SDL, give it a try. Right, this was intentional. I think it's weird that a window would steal input when the mouse moves over it breaking desktop accelerators like alt tab. If you've ever alt-tab cycled through windows when QEMU is running, if you're unlucky enough to have the mouse where a QEMU window may be, the QEMU instance will steal input and prevent alt-tab from working anymore. This would be a usability regression. It is very unhandy to switch between grabbed and ungrabbed, specifically for alt-tab, when working with guests vs. host windows. Look e.g. at how rdeskop works in this regard. That's why I introduced this feature to QEMU, and I would not want to see it die again with the introduction of GTK. I'll add a Grab on Hover menu item to enable the behavior. It's a good excuse to look at gconf to store GUI preferences too. Perfect. - window not resizable (except in broken full-screen mode) That's intentional. And a mistake IMHO. Definitely for the text consoles, but one can also argue about the guest graphic console. I think Stefano once introduced this for some Xen use case, maybe he can comment on it. If we added resize, I wouldn't want to scale-to-size. I find this behavior to be more trouble than it's worth. I'd want to render the VGA screen with a black border only scaling based on the zoom settings. OK for aspect-ratio-correct scaling of the guest view from my POV. And if there is a use case for the old behavior, we could still add a switch to the menu for selecting the scaling mode. Okay, I'll look into it. BTW, VGA is the wrong term for the graphic console. Maybe there is the real front-end name available somewhere and could be used instead. Any suggestions? Display? Graphics? Or were you thinking something like Cirrus VGA? VGA is (mostly) x86. Also, we may once have multiple guest screens, maybe even multiple types of them. So picking up some telling front-end name would likely scale best. Display 0? I think Monitor would be more natural but obviously that would conflict with the human monitor. It might also be something else than a monitor that visualizes guest graphic-like output. Another effect I just noticed: The scroll position of the monitor console is not always properly restored when switching from other consoles. Looks like it can move down, leaving the visible range after some switches. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
Am 27.02.2012 00:46, schrieb Anthony Liguori: I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. The two pieces of feedback I've gotten the most re: accessibility are the lack of QEMU's enablement for screen readers and the lack of configurable accelerators. Since we render our own terminal using a fixed sized font, we don't respect system font settings which means we ignore if the user has configured large print. We also don't integrate at all with screen readers which means that for blind users, the virtual consoles may as well not even exist. We also don't allow any type of configuration of accelerators. For users with limited dexterity (this is actually more common than you would think), they may use an input device that only inputs one key at a time. Holding down two keys at once is not possible for these users. These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). I'm not attempting to make a pretty desktop virtualization UI. Maybe we'll go there eventually but that's not what this series is about. This is just attempting to use a richer toolkit such that we can enable basic accessibility support. As a consequence, the UI is much more usable even for a user without accessibility requirements so it's a win-win. Also available at: https://github.com/aliguori/qemu/tree/gtk.2 --- v1 - v2 - Add internationalization support. I don't actually speak any other languages so I added a placeholder for a German translation. This can be tested with LANGUAGE=de_DE.UTF-8 qemu-system-x86_64 Looks like I need to 'make install' before I can use the translations? I don't have any qemu version installed into the system, but always run it from to build directory (I would only confuse the different trees if something was installed). Shouldn't it be possible that qemu finds the right files just like it does with the BIOS etc.? - Fixed the terminal size for VteTerminal widgets. I think the behavior makes sense now. - Fixed lots of issues raised in review comments (see individual patches) Known Issues: - I saw the X crash once. I think it has to do with widget sizes. I need to work harder to reproduce. - I've not recreated the reported memory leak yet. - I haven't added backwards compatibility code for older VteTerminal widgets yet. - F10 still activates the menu (same for Alt-F/V) Kevin
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 02/27/2012 08:24 AM, Kevin Wolf wrote: Am 27.02.2012 00:46, schrieb Anthony Liguori: I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. The two pieces of feedback I've gotten the most re: accessibility are the lack of QEMU's enablement for screen readers and the lack of configurable accelerators. Since we render our own terminal using a fixed sized font, we don't respect system font settings which means we ignore if the user has configured large print. We also don't integrate at all with screen readers which means that for blind users, the virtual consoles may as well not even exist. We also don't allow any type of configuration of accelerators. For users with limited dexterity (this is actually more common than you would think), they may use an input device that only inputs one key at a time. Holding down two keys at once is not possible for these users. These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). I'm not attempting to make a pretty desktop virtualization UI. Maybe we'll go there eventually but that's not what this series is about. This is just attempting to use a richer toolkit such that we can enable basic accessibility support. As a consequence, the UI is much more usable even for a user without accessibility requirements so it's a win-win. Also available at: https://github.com/aliguori/qemu/tree/gtk.2 --- v1 - v2 - Add internationalization support. I don't actually speak any other languages so I added a placeholder for a German translation. This can be tested with LANGUAGE=de_DE.UTF-8 qemu-system-x86_64 Looks like I need to 'make install' before I can use the translations? I don't have any qemu version installed into the system, but always run it from to build directory (I would only confuse the different trees if something was installed). Shouldn't it be possible that qemu finds the right files just like it does with the BIOS etc.? It's a little harder because of the way gettext works. You can only have a single search path AFAICT. We could add a --with-localedir= to configure and then rearrange the po/ structure. Then you would do something like: ./configure --with-localedir=$(pwd)/po And it would use translations from your build directory. - Fixed the terminal size for VteTerminal widgets. I think the behavior makes sense now. - Fixed lots of issues raised in review comments (see individual patches) Known Issues: - I saw the X crash once. I think it has to do with widget sizes. I need to work harder to reproduce. - I've not recreated the reported memory leak yet. - I haven't added backwards compatibility code for older VteTerminal widgets yet. - F10 still activates the menu (same for Alt-F/V) This is expected behavior although Grab on Hover will cause it to behave like SDL does. F10/Alt-F/V are menu accelerators and we need to allow menu accelerators for things like Ctrl-Alt-2 to work. More importantly, it should be possible to navigate the GUI without a mouse (this is an accessibility requirement). Without supporting Alt-F, there's no way to navigate the menu from the keyboard. That said, we probably do want to add a Send Key menu for sending key sequences that are used as accelerators. Regards, Anthony Liguo Kevin
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
Am 27.02.2012 15:39, schrieb Anthony Liguori: On 02/27/2012 08:24 AM, Kevin Wolf wrote: Am 27.02.2012 00:46, schrieb Anthony Liguori: I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. The two pieces of feedback I've gotten the most re: accessibility are the lack of QEMU's enablement for screen readers and the lack of configurable accelerators. Since we render our own terminal using a fixed sized font, we don't respect system font settings which means we ignore if the user has configured large print. We also don't integrate at all with screen readers which means that for blind users, the virtual consoles may as well not even exist. We also don't allow any type of configuration of accelerators. For users with limited dexterity (this is actually more common than you would think), they may use an input device that only inputs one key at a time. Holding down two keys at once is not possible for these users. These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). I'm not attempting to make a pretty desktop virtualization UI. Maybe we'll go there eventually but that's not what this series is about. This is just attempting to use a richer toolkit such that we can enable basic accessibility support. As a consequence, the UI is much more usable even for a user without accessibility requirements so it's a win-win. Also available at: https://github.com/aliguori/qemu/tree/gtk.2 --- v1 - v2 - Add internationalization support. I don't actually speak any other languages so I added a placeholder for a German translation. This can be tested with LANGUAGE=de_DE.UTF-8 qemu-system-x86_64 Looks like I need to 'make install' before I can use the translations? I don't have any qemu version installed into the system, but always run it from to build directory (I would only confuse the different trees if something was installed). Shouldn't it be possible that qemu finds the right files just like it does with the BIOS etc.? It's a little harder because of the way gettext works. You can only have a single search path AFAICT. We could add a --with-localedir= to configure and then rearrange the po/ structure. Then you would do something like: ./configure --with-localedir=$(pwd)/po And it would use translations from your build directory. Yeah, would be better than nothing. - Fixed the terminal size for VteTerminal widgets. I think the behavior makes sense now. - Fixed lots of issues raised in review comments (see individual patches) Known Issues: - I saw the X crash once. I think it has to do with widget sizes. I need to work harder to reproduce. - I've not recreated the reported memory leak yet. - I haven't added backwards compatibility code for older VteTerminal widgets yet. - F10 still activates the menu (same for Alt-F/V) This is expected behavior although Grab on Hover will cause it to behave like SDL does. At least grabbing the keyboard manually with Ctrl-Alt-G doesn't disable the accelerators, so even then you can't use these keys inside the VM. F10/Alt-F/V are menu accelerators and we need to allow menu accelerators for things like Ctrl-Alt-2 to work. More importantly, it should be possible to navigate the GUI without a mouse (this is an accessibility requirement). Without supporting Alt-F, there's no way to navigate the menu from the keyboard. That said, we probably do want to add a Send Key menu for sending key sequences that are used as accelerators. Probably. But not for things as common as Alt-F, Alt-V or F10. Having to use sendkey or the menus for these would be ridiculous and make SDL the friendlier user interface again. Can accelerators only be enabled or disabled all at once? Or could we say that we disable everything that doesn't include Ctrl-Alt and provide an alternative accelerator for activating the menu, like Ctrl_Alt-M? Kevin
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
Hi, That all keyboard inputs are grabbed when the mouse is in the window and you don't need to press ctrl-alt-g explicitly. And the reverse should happen when the mouse reaches the window border. Just like under SDL, give it a try. Right, this was intentional. I think it's weird that a window would steal input when the mouse moves over it breaking desktop accelerators like alt tab. If you've ever alt-tab cycled through windows when QEMU is running, if you're unlucky enough to have the mouse where a QEMU window may be, the QEMU instance will steal input and prevent alt-tab from working anymore. Same is true the other way around. Working in the guest, then have the host desktop grab accelerators can be annoying too. You might have wanted switch *guest* windows with alt tab ;) It is a tricky usability issue. cheers, Gerd
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On 02/27/2012 10:39 AM, Gerd Hoffmann wrote: Hi, That all keyboard inputs are grabbed when the mouse is in the window and you don't need to press ctrl-alt-g explicitly. And the reverse should happen when the mouse reaches the window border. Just like under SDL, give it a try. Right, this was intentional. I think it's weird that a window would steal input when the mouse moves over it breaking desktop accelerators like alt tab. If you've ever alt-tab cycled through windows when QEMU is running, if you're unlucky enough to have the mouse where a QEMU window may be, the QEMU instance will steal input and prevent alt-tab from working anymore. Same is true the other way around. Working in the guest, then have the host desktop grab accelerators can be annoying too. You might have wanted switch *guest* windows with alt tab ;) It is a tricky usability issue. Clearly, the GUI needs to read the user's mind to figure out what they meant to do :-) I think a menu option at least let's the user choose the behavior. I think that's the best we're going to be able to do. Regards, Anthony Liguori cheers, Gerd
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
Hi, Clearly, the GUI needs to read the user's mind to figure out what they meant to do :-) Fine with me. /me looks forward reviewing patches. cheers, Gerd
[Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. The two pieces of feedback I've gotten the most re: accessibility are the lack of QEMU's enablement for screen readers and the lack of configurable accelerators. Since we render our own terminal using a fixed sized font, we don't respect system font settings which means we ignore if the user has configured large print. We also don't integrate at all with screen readers which means that for blind users, the virtual consoles may as well not even exist. We also don't allow any type of configuration of accelerators. For users with limited dexterity (this is actually more common than you would think), they may use an input device that only inputs one key at a time. Holding down two keys at once is not possible for these users. These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). I'm not attempting to make a pretty desktop virtualization UI. Maybe we'll go there eventually but that's not what this series is about. This is just attempting to use a richer toolkit such that we can enable basic accessibility support. As a consequence, the UI is much more usable even for a user without accessibility requirements so it's a win-win. Also available at: https://github.com/aliguori/qemu/tree/gtk.2 --- v1 - v2 - Add internationalization support. I don't actually speak any other languages so I added a placeholder for a German translation. This can be tested with LANGUAGE=de_DE.UTF-8 qemu-system-x86_64 - Fixed the terminal size for VteTerminal widgets. I think the behavior makes sense now. - Fixed lots of issues raised in review comments (see individual patches) Known Issues: - I saw the X crash once. I think it has to do with widget sizes. I need to work harder to reproduce. - I've not recreated the reported memory leak yet. - I haven't added backwards compatibility code for older VteTerminal widgets yet.
Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
On Sun, 26 Feb 2012, Anthony Liguori wrote: I realize UIs are the third rail of QEMU development, but over the years I've gotten a lot of feedback from users about our UI. I think everyone struggles with the SDL interface and its lack of discoverability but it's worse than I think most people realize for users that rely on accessibility tools. The two pieces of feedback I've gotten the most re: accessibility are the lack of QEMU's enablement for screen readers and the lack of configurable accelerators. Since we render our own terminal using a fixed sized font, we don't respect system font settings which means we ignore if the user has configured large print. We also don't integrate at all with screen readers which means that for blind users, the virtual consoles may as well not even exist. We also don't allow any type of configuration of accelerators. For users with limited dexterity (this is actually more common than you would think), they may use an input device that only inputs one key at a time. Holding down two keys at once is not possible for these users. These are solved problems though and while we could reinvent all of this ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK, solve these problems. By using GTK, we can leverage VteTerminal for screen reader integration and font configuration. We can also use GTK's accelerator support to make accelerators configurable (Gnome provides a global accelerator configuration interface). I'm not attempting to make a pretty desktop virtualization UI. Maybe we'll go there eventually but that's not what this series is about. This is just attempting to use a richer toolkit such that we can enable basic accessibility support. As a consequence, the UI is much more usable even for a user without accessibility requirements so it's a win-win. Also available at: https://github.com/aliguori/qemu/tree/gtk.2 --- v1 - v2 - Add internationalization support. I don't actually speak any other languages so I added a placeholder for a German translation. This can be tested with LANGUAGE=de_DE.UTF-8 qemu-system-x86_64 gnome-terminal, well basically every terminal that isn't konsole, is utterly incapable of rendering anything with complex shaping (devanagari/gurumukhi/whatever for instance), i'd go on a limb and say that it's defficiency in the underlying terminal emulation (VteTerminal?), so claiming to support internationalization is disingenuous. - Fixed the terminal size for VteTerminal widgets. I think the behavior makes sense now. - Fixed lots of issues raised in review comments (see individual patches) Known Issues: - I saw the X crash once. I think it has to do with widget sizes. I need to work harder to reproduce. - I've not recreated the reported memory leak yet. - I haven't added backwards compatibility code for older VteTerminal widgets yet. -- mailto:av1...@comtv.ru
