qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] SDL2 UI behavior of switching views


From: BALATON Zoltan
Subject: Re: [Qemu-devel] SDL2 UI behavior of switching views
Date: Tue, 30 Jan 2018 21:09:57 +0100 (CET)
User-agent: Alpine 2.21 (BSF 202 2017-01-01)

On Tue, 30 Jan 2018, Gerd Hoffmann wrote:
SDL1 has a single window for all consoles.
SDL2 has one window for each console.

Fixed.  Not switchable, neither for SDL1 nor for SDL2.

It sure is possible to make it runtime switchable, but I expect it is
more much difficuilt to code up when compared to gtk due to the lack of
widgets.  gtk has one widget per console, I can hook the console widgets
into my widget/window tree as I like and gtk handles alot of the
management for me.

I think it does not have to be runtime switchable in the sense that the setting does not need to be changable during run (like in gtk) because we don't have a UI for changing it anyway. It's enough to have an option to decide it once at startup, in case that's easier to implement. If not then I guess this will remain as it is now but it's unfortunate to change the previous behaviour with a version change for no good reason.

But feel free to try and send patches.

Unortunately I know nothing about this code and don't have time nor much inclination to learn it now. So unless you can at least give some hints on what would need to be done I can't send patches for this.

Can't see much of a difference here.  gtk has a menu bar, sdl hasn't,
otherwise the two look the same and most hotkeys are the same too.

Adding an option to hide the gtk menu bar shouldn't be much of an issue,
some code for that is already there as gtk hides the menu bar in
fullscreen mode.

There's also a version change going on on the gtk side moving from gtk 2 to 3 which brought similar issues: old behaviour is changed and not working the same way any more, themes are broken, more dependencies introduced and so on. (Not specifically in QEMU but generally for all gtk apps.) Using SDL was also a way to avoid those problems, but then it all happens there again.

I think at the end of the day it boils down to personal preference.
Which is perfectly fine.  But it needs someone who finds sdl important
enough to step up and care about it.

I think people who used SDL so far were happy with the way it worked before and that's why there wasn't a need to change until now that a version update brought unexpected UI changes.

Regards,
BALATON Zoltan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]