Qt / KDE GUI Thread

[Tillin9]

Okay, for the past couple of weeks I've been playing around with getting a Qt GUI for Mupen64Plus. I put an early screenshot of my mockup here:
http://www.emutalk.net/showthread.php?t=42770&page=7

I ran into a few snags so I thought I'd start a thread to talk about them.

The over arching issue is that we need to decide if this is a Qt GUI or a KDE GUI. Under Linux basically Qt = KDE, but as I've come to learn over the past few weeks this is not the case on other platforms. Trying to make a GUI that links only to the Qt libs is not that easy once the program becomes complex enough. Before mupen I never really had reason to try to make a more complex Qt only app, so this came as a bit of a surprise.

Basically the whole problem comes down to: Why do we want a Qt / KDE GUI?

My personal reason is I like all my applications to have the same look and feel and since I run KDE, and rarely use an app that doesn't have a K in front of it, the gtk based GUI looks very out of place on my desktop next to my various Konsole, Kwrite, Konqueror, and Kpdf windows. Kopete and Ktorrent round out my 6 most used apps. If the other users who want a Qt GUI are all KDE users and want it for the same reason, then I should probably just make it a full blown KDE app and feel free to use whatever K routines. This actually would make things easiest on me. However, I don't want to make a decision which will later become an issue.

Using KDE libs on a non-linux platform is an issue since most Mac / Windows users don't have them installed nor want to have to install additional libraries to use the emulator. Using pure Qt makes things a little harder and never quite gets things perfect in KDE. The most severe manifestation of this problem, thus far, is that Qt doesn't have the KDE::Toolbar class which is what gives nice toolbars. See the screenshot comparing the Kwrite toolbar to the current toolbar in my mockup.

Another issue are the icons. I personally like our new gtk icons. However, KDE has standard icons for the functions they represent. I configured my mockup to use the defaults. This lets the app get skinned properly along with other KDE / Qt apps. Of course my code looks to see if these directories are populated and if not fall back to the current icon set. This again comes down to why we'd want a Qt based app unless we're on a KDE system.

Other GUI issues, not purely limited to a Qt / KDE GUI, such as Accelerators and shotcut keys are also something which we should come to some agreement on. Right now the gtk GUI has no working accelerators, though it does have some indicated.

The only shortcut keys I know of are:
Alt-Enter - Fullscreen

(Note: I looked through the source a few times but can't find where these are declared. Yes, I know I have a severe lack of gtk knowledge.)

[Surkow]

I don't know what you can do best. But most of the time I use the Cleanlooks theme in Gnome for Qt based applications like SMPlayer etc. I have no issues using kde libraries in Gnome at all.

[Richard42]

Other GUI issues, not purely limited to a Qt / KDE GUI, such as Accelerators and shotcut keys are also something which we should come to some agreement on. Right now the gtk GUI has no working accelerators, though it does have some indicated.

The only shortcut keys I know of are:
Alt-Enter - Fullscreen

(Note: I looked through the source a few times but can't find where these are declared. Yes, I know I have a severe lack of gtk knowledge.)

There is a list of key commands in the included README file, and on the Google Code site. But these keys are not handled by the GUI - they are processed in the SDL event loop in the emulator itself. From a usability standpoint, it does not make sense for any core emulator functions other than high-level ones like play, stop, or pause, to be controlled by the GUI. The GUI's purpose should be to present a nice interface for configuration and game selection, but after launching the emulator it should get out of the way.

On the Qt/KDE issue, I would say there's probably no harm in using the KDE libs as long as they're available on Linux systems using Gnome as the desktop environment. We're not targeting Win32 or OSX right now, so it doesn't make sense to leave out desirable features for the sake of a platform that we're not supporting. If someone comes on board and starts working to support to support these platforms then we may revisit this.

[ebenblues]

Basically the whole problem comes down to: Why do we want a Qt / KDE GUI?

I think consistency of look and feel is the main reason why we would want this. It may seem like a minor issue, but with distros like ubuntu and kubuntu starting to gain more "average" desktop users, consistent look and feel becomes very important to providing a polished product. My vote is to use the kde functions. macos users are probably going to want their own look and feel and I think *BSD users have kde as an option.

[phorsyon]

I vote for the KDE GUI. On Linux systems most people use either Gnome or KDE, so supporting these two with native GUIs should be the goal. The libs are available on all major distributions anyway.

A QT GUI can be a good compromise if you want one single GUI for all platforms, but it will look a bit alien everywhere. OSX users can be very picky about an applications look and feel. So waiting for a OSX developer may be a good idea. Same goes for Win32 (I mean the 'waiting' part not the 'care about look and feel' part ). There are so many Win32 developers, some day someone will join the project.

[nmn]

Since its so high demand, I will begin work on the Windows port if i get the time.

[MasterPhW]

Since its so high demand, I will begin work on the Windows port if i get the time.

Great! Thank you, I think the windows only users will really appreciate it!

[Clements]

I have no objections to QT myself.

QT is being used to replace the GUIs in VBA-M and ZSNES also.

[nmn]

Qt looks native on all versions of Windows and native enough on Mac OS X. If Mac users get picky about it, flame about it, we could just dump OS X...

[Tillin9]

Wow, thanks for the replies. The overwhelmming response seems to be that the GUI should be KDE. This makes things easier for me, so I'll probably have something people can try very soon.

Note, I'm not really understanding the KDE libs in Gnome comments. Gnome users would probably opt to use the gtk GUI (the idea is now mupen will have both) and under Linux / *NIX the vast majority of users have both KDE and gtk libs installed. The Qt != KDE issue is only really relevant for using Qt in the Mac and Windows ports.

As far as the hot keys, thanks for the pointers. I was looking in the wrong place, so no wonder I didn't see them. Qt's convention is to put the hotkey next to the menu item. I happen to like this since it makes it easy to know what the hotkeys are. For some things, this just means extra text and no code. For others, like the save 'slots', we'd want a Qt signal and slot that updates which one is selected in the GUI even if that slot function doesn't actually toggle the save 'slot' in the emulator. I hope that this is clear.

Besides the main windows, (main, ROM browser, config) I have a few other things on my TODO:

1) Serious makeover for Blight's GUI. I have a friend making a 3D model of an N64 controller in Maya for this one.
2) Make our Rice GUI look the same as the Windows one, i.e. use tabs instead of one big block.

Also, we should come to some consensus on whether it is important to keep the GUI windows smaller than 640x480 so people can run the GUI via TV out. I know some other emulators have a policy on this.