| Message ID | 1329695104-15174-7-git-send-email-aliguori@us.ibm.com |
|---|---|
| State | New |
| Headers | show |
2012/2/20 Anthony Liguori <aliguori@us.ibm.com>: > A user can still enable SDL with '-sdl' or '-display sdl' but start making the > default display GTK by default. > > I'd also like to deprecate the SDL display and remove it in a few releases. > So, will a win32 native UI be written? If not, it will be nice to keep SDL because GTK huge and not that portable for win32 users. (Live example is FreeArc(GTK) vs PeaZip(QT))
On 02/19/2012 06:15 PM, Roy Tam wrote: > 2012/2/20 Anthony Liguori<aliguori@us.ibm.com>: >> A user can still enable SDL with '-sdl' or '-display sdl' but start making the >> default display GTK by default. >> >> I'd also like to deprecate the SDL display and remove it in a few releases. >> > > So, will a win32 native UI be written? Certainly not by me :-) It sounds easy to do but it's not. I don't know of a widely available terminal widget for Windows. Also, when you look at this GTK UI, there's not a whole lot different in terms of what a Windows UI would look like. > If not, it will be nice to keep > SDL because GTK huge and not that portable for win32 users. Neither are true. GTK is a reasonably small dependency especially given that GLIB is a mandatory dependency. I can't imagine that in terms of binary size, libsdl is much bigger than gtk/gdk. And Windows is extremely well supported by GTK so the portability comment is incorrect. > (Live > example is FreeArc(GTK) vs PeaZip(QT)) I don't view QT as an option for a couple reasons. KDE is a second class citizen in Linux. Most distributions default to Gnome these days and GTK is the toolkit of choice. QT is also primarily a C++ framework, not a C framework. We already make use of glib and GTK integration with a glib application is super easy and nice. QT integration would be much less natural. But I'm not attempting to remove anything in this series. Let's see how things actually work and then in a couple releases, we can make decisions about SDL and what to do with other platforms. I'd prefer to have a single UI but I'm not in a position to rule out platform specific UIs at the moment. Regards, Anthony Liguori
2012/2/20 Anthony Liguori <anthony@codemonkey.ws>: > On 02/19/2012 06:15 PM, Roy Tam wrote: >> >> 2012/2/20 Anthony Liguori<aliguori@us.ibm.com>: >>> >>> A user can still enable SDL with '-sdl' or '-display sdl' but start >>> making the >>> default display GTK by default. >>> >>> I'd also like to deprecate the SDL display and remove it in a few >>> releases. >>> >> >> So, will a win32 native UI be written? > > > Certainly not by me :-) It sounds easy to do but it's not. I don't know of > a widely available terminal widget for Windows. Also, when you look at this > GTK UI, there's not a whole lot different in terms of what a Windows UI > would look like. > > >> If not, it will be nice to keep >> SDL because GTK huge and not that portable for win32 users. > > > Neither are true. GTK is a reasonably small dependency especially given > that GLIB is a mandatory dependency. I can't imagine that in terms of > binary size, libsdl is much bigger than gtk/gdk. You didn't count pango, cairo, and libpng in. GTK + GDK + cairo + pango + libpng consume 7.17MB binary size (glib binary is 1.77MB which doesn't count in as SDL version uses glib too), on the contrary SDL.dll is single binary and just ~300KB in size (http://www.libsdl.org/release/SDL-1.2.15-win32.zip). Not to mention the troublesome of recompiling GTK and its dependencies. > > And Windows is extremely well supported by GTK so the portability comment is > incorrect. > I didn't mean the portability of function but portability of binary (no troublesome and hidden settings, easy to put in USB stick and run everywhere) > >> (Live >> example is FreeArc(GTK) vs PeaZip(QT)) > > > I don't view QT as an option for a couple reasons. KDE is a second class > citizen in Linux. Most distributions default to Gnome these days and GTK is > the toolkit of choice. > > QT is also primarily a C++ framework, not a C framework. We already make > use of glib and GTK integration with a glib application is super easy and > nice. QT integration would be much less natural. > > But I'm not attempting to remove anything in this series. Let's see how > things actually work and then in a couple releases, we can make decisions > about SDL and what to do with other platforms. > > I'd prefer to have a single UI but I'm not in a position to rule out > platform specific UIs at the moment. > > Regards, > > Anthony Liguori > >
On Feb 19, 2012 7:50 PM, "Roy Tam" <roytam@gmail.com> wrote: > > 2012/2/20 Anthony Liguori <anthony@codemonkey.ws>: > > On 02/19/2012 06:15 PM, Roy Tam wrote: > >> > >> 2012/2/20 Anthony Liguori<aliguori@us.ibm.com>: > >>> > >>> A user can still enable SDL with '-sdl' or '-display sdl' but start > >>> making the > >>> default display GTK by default. > >>> > >>> I'd also like to deprecate the SDL display and remove it in a few > >>> releases. > >>> > >> > >> So, will a win32 native UI be written? > > > > > > Certainly not by me :-) It sounds easy to do but it's not. I don't know of > > a widely available terminal widget for Windows. Also, when you look at this > > GTK UI, there's not a whole lot different in terms of what a Windows UI > > would look like. > > > > > >> If not, it will be nice to keep > >> SDL because GTK huge and not that portable for win32 users. > > > > > > Neither are true. GTK is a reasonably small dependency especially given > > that GLIB is a mandatory dependency. I can't imagine that in terms of > > binary size, libsdl is much bigger than gtk/gdk. > > You didn't count pango, cairo, and libpng in. GTK + GDK + cairo + > pango + libpng consume 7.17MB binary size (glib binary is 1.77MB which > doesn't count in as SDL version uses glib too), on the contrary > SDL.dll is single binary and just ~300KB in size > (http://www.libsdl.org/release/SDL-1.2.15-win32.zip). > Not to mention the troublesome of recompiling GTK and its dependencies. 7MB is far from huge. Having to deal with a few dlls doesn't seem like much of a burden to me. > > > > > And Windows is extremely well supported by GTK so the portability comment is > > incorrect. > > > > I didn't mean the portability of function but portability of binary > (no troublesome and hidden settings, easy to put in USB stick and run > everywhere) Considering that you probably cannot even buy a USB stick smaller than 32MB today, I don't see the logic here. Regards, Anthony Liguori > > > >> (Live > >> example is FreeArc(GTK) vs PeaZip(QT)) > > > > > > I don't view QT as an option for a couple reasons. KDE is a second class > > citizen in Linux. Most distributions default to Gnome these days and GTK is > > the toolkit of choice. > > > > QT is also primarily a C++ framework, not a C framework. We already make > > use of glib and GTK integration with a glib application is super easy and > > nice. QT integration would be much less natural. > > > > But I'm not attempting to remove anything in this series. Let's see how > > things actually work and then in a couple releases, we can make decisions > > about SDL and what to do with other platforms. > > > > I'd prefer to have a single UI but I'm not in a position to rule out > > platform specific UIs at the moment. > > > > Regards, > > > > Anthony Liguori > > > >
On 19/02/12 8:10 PM, Anthony Liguori wrote: >> If not, it will be nice to keep >> SDL because GTK huge and not that portable for win32 users. > > Neither are true. GTK is a reasonably small dependency especially given > that GLIB is a mandatory dependency. I can't imagine that in terms of > binary size, libsdl is much bigger than gtk/gdk. Double check your facts. That's not even close to being true. SDL is a tiny fraction of Gtk+. Just as an example taking a look at package sizes.. 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries) excluding Glib2 and what it depends on. Glib2 and dependencies are 14.5MB (5 libraries). The two in total drag in 12 libraries at 31MBs. That's IMO a fair bit larger than QEMU itself at 25.9MB.
On 02/19/2012 08:24 PM, Brad Smith wrote: > On 19/02/12 8:10 PM, Anthony Liguori wrote: >>> If not, it will be nice to keep >>> SDL because GTK huge and not that portable for win32 users. >> >> Neither are true. GTK is a reasonably small dependency especially given >> that GLIB is a mandatory dependency. I can't imagine that in terms of >> binary size, libsdl is much bigger than gtk/gdk. > > Double check your facts. That's not even close to being true. > > SDL is a tiny fraction of Gtk+. > > Just as an example taking a look at package sizes.. > > 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries) > excluding Glib2 and what it depends on. I don't see how 17.3MB qualifies as "huge". Regards, Anthony Liguori Glib2 and dependencies are 14.5MB > (5 libraries). The two in total drag in 12 libraries at 31MBs. That's IMO > a fair bit larger than QEMU itself at 25.9MB. >
2012/2/20 Anthony Liguori <anthony@codemonkey.ws>: > On 02/19/2012 08:24 PM, Brad Smith wrote: >> >> On 19/02/12 8:10 PM, Anthony Liguori wrote: >>>> >>>> If not, it will be nice to keep >>>> SDL because GTK huge and not that portable for win32 users. >>> >>> >>> Neither are true. GTK is a reasonably small dependency especially given >>> that GLIB is a mandatory dependency. I can't imagine that in terms of >>> binary size, libsdl is much bigger than gtk/gdk. >> >> >> Double check your facts. That's not even close to being true. >> >> SDL is a tiny fraction of Gtk+. >> >> Just as an example taking a look at package sizes.. >> >> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries) >> excluding Glib2 and what it depends on. > > > I don't see how 17.3MB qualifies as "huge". You have to compare the SDL library with GTK and its dependencies. SDL is "small" while 32-times-bigger GTK libraries should qualify as "huge". > > Regards, > > Anthony Liguori > > > Glib2 and dependencies are 14.5MB >> >> (5 libraries). The two in total drag in 12 libraries at 31MBs. That's IMO >> a fair bit larger than QEMU itself at 25.9MB. >> >
On 19/02/12 9:44 PM, Anthony Liguori wrote: > On 02/19/2012 08:24 PM, Brad Smith wrote: >> On 19/02/12 8:10 PM, Anthony Liguori wrote: >>>> If not, it will be nice to keep >>>> SDL because GTK huge and not that portable for win32 users. >>> >>> Neither are true. GTK is a reasonably small dependency especially given >>> that GLIB is a mandatory dependency. I can't imagine that in terms of >>> binary size, libsdl is much bigger than gtk/gdk. >> >> Double check your facts. That's not even close to being true. >> >> SDL is a tiny fraction of Gtk+. >> >> Just as an example taking a look at package sizes.. >> >> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries) >> excluding Glib2 and what it depends on. > > I don't see how 17.3MB qualifies as "huge". It's FAR from small not to mention dragging in A LOT of libraries for what? A prettier looking UI?
On 02/19/2012 08:52 PM, Brad Smith wrote: > On 19/02/12 9:44 PM, Anthony Liguori wrote: >> On 02/19/2012 08:24 PM, Brad Smith wrote: >>> On 19/02/12 8:10 PM, Anthony Liguori wrote: >>>>> If not, it will be nice to keep >>>>> SDL because GTK huge and not that portable for win32 users. >>>> >>>> Neither are true. GTK is a reasonably small dependency especially given >>>> that GLIB is a mandatory dependency. I can't imagine that in terms of >>>> binary size, libsdl is much bigger than gtk/gdk. >>> >>> Double check your facts. That's not even close to being true. >>> >>> SDL is a tiny fraction of Gtk+. >>> >>> Just as an example taking a look at package sizes.. >>> >>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries) >>> excluding Glib2 and what it depends on. >> >> I don't see how 17.3MB qualifies as "huge". > > It's FAR from small not to mention dragging in A LOT of libraries for what? > A prettier looking UI? An accessible UI that meets the most basic definition of usable. Sit someone down with the SDL interface for the first time, how in the world are they supposed to figure out that you hit Ctrl+Alt+2 to get to a command prompt? If they somehow figure that out and think to type help in the monitor, they need to someone figure out to use Ctrl-PageUp to actually read the help text. If you don't want to have to worry about dependencies, use an OS that has a proper package management system so you don't have to deal with these things. Regards, Anthony Liguori
On Mon, 20 Feb 2012, Anthony Liguori wrote: > On 02/19/2012 08:52 PM, Brad Smith wrote: > > On 19/02/12 9:44 PM, Anthony Liguori wrote: > >> On 02/19/2012 08:24 PM, Brad Smith wrote: > >>> On 19/02/12 8:10 PM, Anthony Liguori wrote: > >>>>> If not, it will be nice to keep > >>>>> SDL because GTK huge and not that portable for win32 users. > >>>> > >>>> Neither are true. GTK is a reasonably small dependency especially given > >>>> that GLIB is a mandatory dependency. I can't imagine that in terms of > >>>> binary size, libsdl is much bigger than gtk/gdk. > >>> > >>> Double check your facts. That's not even close to being true. > >>> > >>> SDL is a tiny fraction of Gtk+. > >>> > >>> Just as an example taking a look at package sizes.. > >>> > >>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries) > >>> excluding Glib2 and what it depends on. > >> > >> I don't see how 17.3MB qualifies as "huge". > > > > It's FAR from small not to mention dragging in A LOT of libraries for what? > > A prettier looking UI? > > An accessible UI that meets the most basic definition of usable. Sit someone > down with the SDL interface for the first time, how in the world are they > supposed to figure out that you hit Ctrl+Alt+2 to get to a command prompt? I think that having a GTK UI is quite important for QEMU and having it be the default is also a good idea. BUT we should not deprecate and plan to remove SDL. Do we really want to force everybody that uses QEMU on X11 to compile the entire set of GTK dependencies? Keep in mind that QEMU is not just used on Linux distros but it also used as a component in other projects that might have very different constraints. I think that having a lightweight graphical UI with very few and small dependencies is NOT something we should give up.
On 02/20/2012 08:06 AM, Stefano Stabellini wrote: > On Mon, 20 Feb 2012, Anthony Liguori wrote: >> On 02/19/2012 08:52 PM, Brad Smith wrote: >>> On 19/02/12 9:44 PM, Anthony Liguori wrote: >>>> On 02/19/2012 08:24 PM, Brad Smith wrote: >>>>> On 19/02/12 8:10 PM, Anthony Liguori wrote: >>>>>>> If not, it will be nice to keep >>>>>>> SDL because GTK huge and not that portable for win32 users. >>>>>> >>>>>> Neither are true. GTK is a reasonably small dependency especially given >>>>>> that GLIB is a mandatory dependency. I can't imagine that in terms of >>>>>> binary size, libsdl is much bigger than gtk/gdk. >>>>> >>>>> Double check your facts. That's not even close to being true. >>>>> >>>>> SDL is a tiny fraction of Gtk+. >>>>> >>>>> Just as an example taking a look at package sizes.. >>>>> >>>>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries) >>>>> excluding Glib2 and what it depends on. >>>> >>>> I don't see how 17.3MB qualifies as "huge". >>> >>> It's FAR from small not to mention dragging in A LOT of libraries for what? >>> A prettier looking UI? >> >> An accessible UI that meets the most basic definition of usable. Sit someone >> down with the SDL interface for the first time, how in the world are they >> supposed to figure out that you hit Ctrl+Alt+2 to get to a command prompt? > > I think that having a GTK UI is quite important for QEMU and having it > be the default is also a good idea. > > BUT we should not deprecate and plan to remove SDL. Actually, I think Cairo can be a better SDL than SDL. It doesn't have the same level of backend support (or input support) as SDL does, but it can render to Win32, Quartz, and a raw X11 window. > Do we really want to force everybody that uses QEMU on X11 to compile > the entire set of GTK dependencies? > Keep in mind that QEMU is not just used on Linux distros but it also > used as a component in other projects that might have very different > constraints. > I think that having a lightweight graphical UI with very few and small > dependencies is NOT something we should give up. If we went in a different direction with SDL, I wouldn't mind it so much. For instance, removing the console emulation and reducing the use of magic accelerators. Regards, Anthony Liguori
On Mon, 20 Feb 2012, Anthony Liguori wrote: > On 02/20/2012 08:06 AM, Stefano Stabellini wrote: > > On Mon, 20 Feb 2012, Anthony Liguori wrote: > >> On 02/19/2012 08:52 PM, Brad Smith wrote: > >>> On 19/02/12 9:44 PM, Anthony Liguori wrote: > >>>> On 02/19/2012 08:24 PM, Brad Smith wrote: > >>>>> On 19/02/12 8:10 PM, Anthony Liguori wrote: > >>>>>>> If not, it will be nice to keep > >>>>>>> SDL because GTK huge and not that portable for win32 users. > >>>>>> > >>>>>> Neither are true. GTK is a reasonably small dependency especially given > >>>>>> that GLIB is a mandatory dependency. I can't imagine that in terms of > >>>>>> binary size, libsdl is much bigger than gtk/gdk. > >>>>> > >>>>> Double check your facts. That's not even close to being true. > >>>>> > >>>>> SDL is a tiny fraction of Gtk+. > >>>>> > >>>>> Just as an example taking a look at package sizes.. > >>>>> > >>>>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries) > >>>>> excluding Glib2 and what it depends on. > >>>> > >>>> I don't see how 17.3MB qualifies as "huge". > >>> > >>> It's FAR from small not to mention dragging in A LOT of libraries for what? > >>> A prettier looking UI? > >> > >> An accessible UI that meets the most basic definition of usable. Sit someone > >> down with the SDL interface for the first time, how in the world are they > >> supposed to figure out that you hit Ctrl+Alt+2 to get to a command prompt? > > > > I think that having a GTK UI is quite important for QEMU and having it > > be the default is also a good idea. > > > > BUT we should not deprecate and plan to remove SDL. > > Actually, I think Cairo can be a better SDL than SDL. > > It doesn't have the same level of backend support (or input support) as SDL > does, but it can render to Win32, Quartz, and a raw X11 window. Cairo seems to be quite popular and well maintained, however I am not sure how well it would work without GTK. Granted that I don't particularly care about which library we use for rendering the "lightweight UI", if the entire UI can be written in Cairo, without any other library or dependency of any kind, then it is probably OK to replace SDL with Cairo. > > Do we really want to force everybody that uses QEMU on X11 to compile > > the entire set of GTK dependencies? > > Keep in mind that QEMU is not just used on Linux distros but it also > > used as a component in other projects that might have very different > > constraints. > > I think that having a lightweight graphical UI with very few and small > > dependencies is NOT something we should give up. > > If we went in a different direction with SDL, I wouldn't mind it so much. For > instance, removing the console emulation and reducing the use of magic accelerators. Strictly speaking the console emulation is not part of the SDL UI, also we need to keep it because of VNC. But I agree that the SDL UI should stay light and simple, rather than duplicating the fully featured desktop experience that is going to be provided by GTK.
2012/2/20 Stefano Stabellini <stefano.stabellini@eu.citrix.com>: > On Mon, 20 Feb 2012, Anthony Liguori wrote: >> On 02/20/2012 08:06 AM, Stefano Stabellini wrote: >> > On Mon, 20 Feb 2012, Anthony Liguori wrote: >> >> On 02/19/2012 08:52 PM, Brad Smith wrote: >> >>> On 19/02/12 9:44 PM, Anthony Liguori wrote: >> >>>> On 02/19/2012 08:24 PM, Brad Smith wrote: >> >>>>> On 19/02/12 8:10 PM, Anthony Liguori wrote: >> >>>>>>> If not, it will be nice to keep >> >>>>>>> SDL because GTK huge and not that portable for win32 users. >> >>>>>> >> >>>>>> Neither are true. GTK is a reasonably small dependency especially given >> >>>>>> that GLIB is a mandatory dependency. I can't imagine that in terms of >> >>>>>> binary size, libsdl is much bigger than gtk/gdk. >> >>>>> >> >>>>> Double check your facts. That's not even close to being true. >> >>>>> >> >>>>> SDL is a tiny fraction of Gtk+. >> >>>>> >> >>>>> Just as an example taking a look at package sizes.. >> >>>>> >> >>>>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries) >> >>>>> excluding Glib2 and what it depends on. >> >>>> >> >>>> I don't see how 17.3MB qualifies as "huge". >> >>> >> >>> It's FAR from small not to mention dragging in A LOT of libraries for what? >> >>> A prettier looking UI? >> >> >> >> An accessible UI that meets the most basic definition of usable. Sit someone >> >> down with the SDL interface for the first time, how in the world are they >> >> supposed to figure out that you hit Ctrl+Alt+2 to get to a command prompt? >> > >> > I think that having a GTK UI is quite important for QEMU and having it >> > be the default is also a good idea. >> > >> > BUT we should not deprecate and plan to remove SDL. >> >> Actually, I think Cairo can be a better SDL than SDL. >> >> It doesn't have the same level of backend support (or input support) as SDL >> does, but it can render to Win32, Quartz, and a raw X11 window. > > Cairo seems to be quite popular and well maintained, however I am not > sure how well it would work without GTK. > > Granted that I don't particularly care about which library we use for > rendering the "lightweight UI", if the entire UI can be written in > Cairo, without any other library or dependency of any kind, then it > is probably OK to replace SDL with Cairo. > cairo handles display only, you have to deal with input for each platform (which is handled by SDL) > >> > Do we really want to force everybody that uses QEMU on X11 to compile >> > the entire set of GTK dependencies? >> > Keep in mind that QEMU is not just used on Linux distros but it also >> > used as a component in other projects that might have very different >> > constraints. >> > I think that having a lightweight graphical UI with very few and small >> > dependencies is NOT something we should give up. >> >> If we went in a different direction with SDL, I wouldn't mind it so much. For >> instance, removing the console emulation and reducing the use of magic accelerators. > > Strictly speaking the console emulation is not part of the SDL UI, also > we need to keep it because of VNC. > But I agree that the SDL UI should stay light and simple, rather than > duplicating the fully featured desktop experience that is going to be > provided by GTK.
diff --git a/vl.c b/vl.c index d8a521a..ad0b726 100644 --- a/vl.c +++ b/vl.c @@ -3220,6 +3220,25 @@ int main(int argc, char **argv, char **envp) add_device_config(DEV_VIRTCON, "vc:80Cx24C"); } + if (display_type == DT_DEFAULT) { +#if defined(CONFIG_GTK) + display_type = DT_GTK; +#elif defined(CONFIG_SDL) || defined(CONFIG_COCOA) + display_type = DT_SDL; +#elif defined(CONFIG_VNC) + vnc_display = "localhost:0,to=99"; + show_vnc_port = 1; +#else + display_type = DT_NONE; +#endif + } + +#if defined(CONFIG_GTK) + if (display_type == DT_GTK) { + early_gtk_display_init(); + } +#endif + socket_init(); if (qemu_opts_foreach(qemu_find_opts("chardev"), chardev_init_func, NULL, 1) != 0) @@ -3418,20 +3437,6 @@ int main(int argc, char **argv, char **envp) /* just use the first displaystate for the moment */ ds = get_displaystate(); - if (using_spice) - display_remote++; - if (display_type == DT_DEFAULT && !display_remote) { -#if defined(CONFIG_SDL) || defined(CONFIG_COCOA) - display_type = DT_SDL; -#elif defined(CONFIG_VNC) - vnc_display = "localhost:0,to=99"; - show_vnc_port = 1; -#else - display_type = DT_NONE; -#endif - } - - /* init local displays */ switch (display_type) { case DT_NOGRAPHIC: @@ -3450,6 +3455,11 @@ int main(int argc, char **argv, char **envp) cocoa_display_init(ds, full_screen); break; #endif +#if defined(CONFIG_GTK) + case DT_GTK: + gtk_display_init(ds); + break; +#endif default: break; }
A user can still enable SDL with '-sdl' or '-display sdl' but start making the default display GTK by default. I'd also like to deprecate the SDL display and remove it in a few releases. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- vl.c | 38 ++++++++++++++++++++++++-------------- 1 files changed, 24 insertions(+), 14 deletions(-)