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.

 

[Surkow]

[...]

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.

[...]

If the development is mostly going to focus on a new Qt GUI build I have no issues using it. I currently dislike the GTK GUI because it uses the old GTK file dialog and the SDL based input plugin causes 100% cpu usage (you wanted to create a Qt GUI for it if I remember correctly). Most Gnome users would not appreciate KDE libraries loaded on startup. But I use enough other KDE programs that benefit from it.

 

[ebenblues]

I currently dislike the GTK GUI because it uses the old GTK file dialog and the SDL based input plugin causes 100% cpu usage.

Thanks for reporting the file dialog issue. After some research, it appears the current gui uses the GtkFileSelection widget which is deprecated and should be replaced by the GtkFileChooserDialog widget. I've added a new issue to the issue tracker to fix this:

http://code.google.com/p/mupen64plus/issues/detail?id=32

There is also an issue opened for the SDL config dialog. I'm going to work on a port of the config dialog to gtk for v1.4 (hopefully), which should fix the 100% CPU issue, but it will still use the same controller pic that's used today. I'm excited to see the 3D controller model Tillin9's talking about. If people seem to agree that it's better than the current picture, we'll port it to the gtk gui as well.

UPDATE: The file dialog fix turned out to be trivial. I just committed it to svn.

 

[Tillin9]

Okay, so I did some more work and basically determined that if the code is going to be maintainable, a lot more of it needs to be done manually than I first intended. Since there seems to be no easy Qt .ui to code transition and the designer leaves a lot to be desired when doing more than dialogues, I think this is the better path. So, since my experience is primarily on Debian, where do our KDE users have their KDE and Qt includes and libraries?

For me:

KDEINCLUDE = /usr/include/kde
KDELIB S = /usr/lib
QTINCLUDE = /usr/share/qt3/include
QTLIBS = /usr/share/qt3/lib

Doing things manually means we only need the kdelibs and qtlibs to run, and additionally the KDE headers, Qt headers, and Qt MOC to compile. These 4 flags, plus say a OBJ_KDE_GUI and maybe some flag to pick the gtk or KDE GUI (if this wasn't a top level option) would be all the necessary modifications to our build system.

Finally, I noticed that 0-9 is supposed to change the save state. Right now, it doesn't seem to do so, either in the GUI or the emulator. Esc also doesn't quit the emulator, just ends emulation.

 

[Richard42]

KDEINCLUDE = /usr/include/kde
KDELIB S = /usr/lib
QTINCLUDE = /usr/share/qt3/include
QTLIBS = /usr/share/qt3/lib

You can't hard-code these paths in the makefile. The normal way to do this for the QT libraries is like this:

CFLAGS += `pkg-config --cflags qt-mt`
LDFLAGS += `pkg-config --libs qt-mt`

There should be something similar for the KDE libraries.

Finally, I noticed that 0-9 is supposed to change the save state. Right now, it doesn't seem to do so, either in the GUI or the emulator. Esc also doesn't quit the emulator, just ends emulation.

I'm not sure what you mean about the Escape key. It does shut down the emulator, but not the GUI. Escape is not normally used to quit any GUI application, that's usually Alt-F4 or a message like WM_QUIT from the message loop.

If the 0-9 keys are not selecting the load/save slot then that's a bug that we should add to the issue tracker.

 

[ebenblues]

the SDL based input plugin causes 100% cpu usage

FYI, I committed a fix to svn (r90) which should greatly decrease the amount of cpu used by the SDL config dialog in blight_input. Hopefully this helps people out until I port the config dialog to gtk.

 

[Surkow]

Thanks for reporting the file dialog issue. After some research, it appears the current gui uses the GtkFileSelection widget which is deprecated and should be replaced by the GtkFileChooserDialog widget.

[...]

UPDATE: The file dialog fix turned out to be trivial. I just committed it to svn.

Thanks for fixing the dialog.

FYI, I committed a fix to svn (r90) which should greatly decrease the amount of cpu used by the SDL config dialog in blight_input. Hopefully this helps people out until I port the config dialog to gtk.

After compiling the latest svn version I noticed the decreased amount of cpu usage. Sadly enough half of the time it fails to capture my input from my xbox 360 controller (a while back I made a thread about it).

Edit: it seems to work ok now.

 

[Slougi]

Hi, I'm a KDE developer and use Qt professionally at work.

One piece of advise: use Qt4 and/or KDE4. Qt3 and KDE3 is basically dead code that will get only bug fixes in the future.

Also, _do_ use Qt designer. It is very versatile, learn how to use it. Manually coding the ui is _not_ more maintainable at all.

I tried an svn checkout but it seems your repo is unresponsive/broken.

 

[Slougi]

Also, on no platform is Qt == KDE. The KDE libraries extend Qt with extra functionality. Currently kdelibs itself is portable to windows and mac as well. What problems were you seeing trying to link only to Qt?

 

[Tillin9]

None of the KDE GUI stuff is in svn. Mainly since I'm still trying to figure out the best way to do this correctly. I thought it would be easy to go from Qt + KDevelop + (KDevelop's autobuild system) to KDE via texteditor which could be merged with mupen's build system. This is not the case. But hey, part of why I'm working on this is also to learn.

Its nice to have someone more knowledage here.

My main issue is how do I choose KToolbar instead of QToolbar using designer code without overloading? Also, is there a nice .ui -> code tool (i.e. so I can use the designer to design but then modify the things it doesn't have options for) and so I don't have to use the setUi() stuff? The designer seems to leave a lot of options out. Another issue, which may be a version / not being taught issue., but I can't find anything on how one might go about using icons from files at runtime (needed for the KDE skinable icons with fallback) in the designer. Everything I do just embeds the images which we don't want to do. Even for mupen64plus specific images, the resources should be separate so they can be easily incorporated into other GUIs.

My Qt == KDE on Linux comment was that for most simple things nothing visual is changed and contrary to on Windows and OSX, Qt widgets are native widgets. The same appearance comes up in the example that for a simple KDE app, one uses QListView even though there is a KListView class. I also believe that the KDE themes are passed to the relevant Qt engine so both widgets will always look the same (unless one goes to great lengths to give them different themes - this probably involves using Qt-copy or otherwise having two sets of Qt installed). Hence to make a GUI which looked native, if it was simple enough, we'd only need to add a dependence on Qt. KDE4 probably changes the difficulty of compiling the K libraries on other platforms, but when last I checked it was still very painful. I'd love to hear these problems were fixed and there is a nice .exe or .pkg which installs all the dependencies automatically.

Finally, since you said you were a KDE developer, I have a couple general KDE4 questions as I don't really like it yet. Are there any plans for KDE3 widget and iconset converters? My main issue is I dislike the default themes, they violate my #1 rule of UI design of always keeping things looking the same unless there is very, very good reason to change. I personally feel KDE4 looks like an OSX iconset on Vista. However, I do appreciate the speedup, and a lot of the underlying upgrades so I think its just getting some nice classic themes for stubborn olddies like myself.

F.Y.I. - I was taught Qt3 in school, but have a copy of Molkentin's Book of Qt 4 and for the basic things I'm doing I don't see much of a difference. That is I can replace the qt3 with qt4 above and everything still looks the same (though uses my KDE4 theme).

 

[Slougi]

None of the KDE GUI stuff is in svn. Mainly since I'm still trying to figure out the best way to do this correctly. I thought it would be easy to go from Qt + KDevelop + (KDevelop's autobuild system) to KDE via texteditor which could be merged with mupen's build system. This is not the case. But hey, part of why I'm working on this is also to learn.

Well, to be honest I think the current mupen64plus build system is not too nice It would never ever survive a port to windows for example, and I think OS X is doubtful also. I started hacking on a cmake-based system, it builds most things already. blight_input is a little... hairy though at the moment, it needs a few fixes.

Its nice to have someone more knowledage here.

Never said I was knowledgeable

My main issue is how do I choose KToolbar instead of QToolbar using designer code without overloading? Also, is there a nice .ui -> code tool (i.e. so I can use the designer to design but then modify the things it doesn't have options for) and so I don't have to use the setUi() stuff? The designer seems to leave a lot of options out.

Using uic the .ui is converted to a header. You do need to do setupUi somewhere, you can either hide this inside a subclass or do it explicitly. If you use cmake and kde cmake instructions QToolBar, QMenuBar etc. will automatically be converted in the ui file to use their KDE equivalents.

Another issue, which may be a version / not being taught issue., but I can't find anything on how one might go about using icons from files at runtime (needed for the KDE skinable icons with fallback) in the designer.

You need to look into the KAction class and KXMLGUI.

http://techbase.kde.org/index.php?title=Development/Tutorials/Using_KXmlGuiWindow
http://techbase.kde.org/index.php?title=Development/Tutorials/Using_KActions

Everything I do just embeds the images which we don't want to do. Even for mupen64plus specific images, the resources should be separate so they can be easily incorporated into other GUIs.

Right, they should be installed somewhere where they can be found using generic approaches. Also take a look at the Qt resource system that embeds files in the executable

My Qt == KDE on Linux comment was that for most simple things nothing visual is changed and contrary to on Windows and OSX, Qt widgets are native widgets. The same appearance comes up in the example that for a simple KDE app, one uses QListView even though there is a KListView class. I also believe that the KDE themes are passed to the relevant Qt engine so both widgets will always look the same (unless one goes to great lengths to give them different themes - this probably involves using Qt-copy or otherwise having two sets of Qt installed).

There are a few theming things not picked up currently by basic Qt apps when compared to KDE (palette changes for instance). qt-copy isn't really relevant to that.

Hence to make a GUI which looked native, if it was simple enough, we'd only need to add a dependence on Qt.

Well, you will get a native look on windows and mac os x since the actual platform specific libraries are used underneat. You should also be very close to KDE modulo some of the KDE specific things.

KDE4 probably changes the difficulty of compiling the K libraries on other platforms, but when last I checked it was still very painful. I'd love to hear these problems were fixed and there is a nice .exe or .pkg which installs all the dependencies automatically.

http://techbase.kde.org/index.php?title=Projects/KDE_on_Windows
http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X

Finally, since you said you were a KDE developer, I have a couple general KDE4 questions as I don't really like it yet. Are there any plans for KDE3 widget and iconset converters?

KDE4 is compatible with the freedesktop.org icon spec that was established during the KDE3 series. I'm not aware of any converters.

Gnome and KDE4 icon themes should now be interchangeable largely.

My main issue is I dislike the default themes, they violate my #1 rule of UI design of always keeping things looking the same unless there is very, very good reason to change. I personally feel KDE4 looks like an OSX iconset on Vista. However, I do appreciate the speedup, and a lot of the underlying upgrades so I think its just getting some nice classic themes for stubborn olddies like myself.

How am I supposed to comment on this?

F.Y.I. - I was taught Qt3 in school, but have a copy of Molkentin's Book of Qt 4 and for the basic things I'm doing I don't see much of a difference. That is I can replace the qt3 with qt4 above and everything still looks the same (though uses my KDE4 theme).

Good, then just use Qt4