Suggestion: Modular User Interface

[joneslee85]

Hi folks,
Just wondering if you folks out there like the idea of having a modular UI scummVM? If you guys have no idea what modular UI, let me explain to you in simple way:
- Split the core library and GUI
- All games implemenation will be on core library (e.g name it libscummvm - maybe?)
- the GUI will me modular, it could be original GUI, GTK, Qt, etc..).

1. Why do I come up with this idea?
Just imagine if you are running scummVM on GNOME, wouldn't it nicer to have an GTK UI that match the whole desktop? Modular UI will take advantage of UI API designed for specific OS that could improve the UI consistency.

2. Draft plan
+ libscummvm
+ UI
- GTK for GNOME, XFCE, N770
- Qt for KDE
- BeOS's UI Widget for BeOS, ZetaOS, Haiku
- Curses UI for command-line on X Windows
- Native UI SDK for PSP, WinCE, WinMobile, etc.
- Native scummVM for generic OS
- or any Widget UI that scummVM might be ported to

3. What is the advantage?
- The team can be splitted into two. One who will work on implementing the core library. And other works on Frontend UI.
- Improve specific desktop consistency and integration
- Reduce UI bugs - other Widget API is highly more documented, frequently fixed and easier to use than native X scummVM UI

4. What is the disadvantage?
- More modules to maintain. Ofcourse there will be more libs to depend on.
- I reckon I will take up more memory resources since nothing is as light as native UI

[Ender]

ScummVM is already modular enough that this would be possible, so feel free to make a native GUI if you want.

Personally, I think this is a pretty stupid idea myself (no offence) and at least two of your three 'advantages' should be under 'disadvantages' :)

We just implemented a nice new themable GUI, and the very concept of splitting the team in half is a huge disadvantage, not an advantage at all.

Reduce UI bugs? The ScummVM GUI is much easier to bugfix than having to support a dozen different widget libraries, all of which have their own bugs, tweaks and cross-platform issues. Meanwhile our GUI code is quite well tested on pretty much every device known to man, and can be maintained and corrected -instantly- instead of having to wait for upsteam to fix problems in their widgets.


As for whether desktop integration is an advantage, well, thats a personal opinion matter.... Personally I think ScummVMs launcher would look absolutely disgusting implemented as native Win32/GTK widgets...

Really, what game uses native widgets in its UI anyway? (Sure, there are a few, but most of them have really horrible UIs :)

[clem]

oh, and things like this should be submitted to the feature request tracker anyway?

[fingolfin]

Back when I started work on the "new" GUI (the one *before* we had the new themeable GUI, I mean), I was contempleting this (i.e. making it possible to have "native" GUIs for each platform) for a brief time, too.

In the end I rejected it for reasons that are already listed here, but let me repeat them anyway:

Manpower

You need far more manpower to maintain multiple GUIs. Whenever you add something new to the GUI, you have to add it in multiple places UIs. Worse, you probably can't even do that, you have to hope for maintainers to eventually get around to doing it.

This is the killer argument, in my eyes.


Consistency
While native GUIs allos you to become "consistent" with other applications on that particular platform, it becomes very hard, if not impossible, to stay consistent across platforms. Meaning that somebody who knows how to use ScummVM on Windows may have a tough time using it under Mac OS X or KDE or ...

Traditionally, games usually do not care overly much about being consistent with the GUI of their host OS, which is usually OK (some overall guidelines of course should still be followed -- e.g. on OS X, Cmd-Q should always allow you to quit/exit the program, even in a game). OTOH, they do care a lot about having near identical user interfaces across all hosts.


User support

Of course now people will report bugs for each UI, and we need people to handle each (see also "manpower").


In the end it boils down to "much harder to support, needs far more manpower than we have, provides little benefit, and what benefit it provides is of low importance for us".