[Kde-games-devel] Re: Review Request: new libkdegames class KGameBasicWindow to replace KXmlGuiWindow on mobile formfactors

[Ian Wadham]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6744/#review10280
-----------------------------------------------------------


No offence taken re putting "less formal interfaces" in quotes.  It is a normal thing to do.  Point taken re lack of manpower in KDE Games.  Adapting already existing toolbars is a good short-term solution.  I'd suggest however that they might work better on a touch screen if they are put at the bottom of the screen.  But try it and see.  Experimentation must decide. 

- Ian


On July 8, 2011, 11:11 p.m., Stefan Majewsky wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6744/
> -----------------------------------------------------------
> 
> (Updated July 8, 2011, 11:11 p.m.)
> 
> 
> Review request for KDE Games and usability.
> 
> 
> Summary
> -------
> 
> General outline: Many games present only a small set of menuitems and toolbar actions to the user. Even on mobile form factors, all relevant actions can in many cases easily fit in the toolbar, thus removing the need for the (touch-unfriendly) and redundant menubar. On the implementation side, it would be beneficial to replace KXmlGuiWindow, which provides important features to desktop apps, but overcomplicates the problem for apps as simple as most games.
> 
> Solution: The new KGameBasicWindow class provides a hard-coded toolbar arrangement, in which only one toolbar is created at the top of the window. The most relevant actions are placed here directly, like one expects for a toolbar. Less used actions (like those commonly found in the "Settings" and "Help" menu) can be placed in a hierarchy, but only one level of the hierarchy is made visible at once in the toolbar.
> 
> For example, if the user wants to open the handbook, he finds the "Help" button on the toolbar. Upon clicking it, the toolbar changes and displays all actions in the "Help" group (plus a "Back" button). After selecting the "Handbook" action (and thus opening the handbook), the toolbar automatically returns to its default setup and presents the "important" actions again.
> 
> Open question: Should this approach be limited to mobile formfactors, or be used on the desktop also? Of course, I'm only speaking about those games where the action set is really so small that KGameBasicWindow "works" (e.g. KDiamond, e.g. NOT KGoldRunner, e.g. Bomber, e.g. NOT KTuberling). CCing usability folks for their input on whether I'm violating the HIG too much. ;-)
> 
> Implementation: KGameBasicWindow is a new class in libkdegames. Besides this new class, the only change is in KGameDifficulty, whose init() function may now take not only KXmlGuiWindows, but also KGameBasicWindows. This change is trivial because KGameBasicWindow provides an action collection, too.
> 
> What's missing? The standard dialog for editing shortcuts. Also, I have not yet decided on how to decide between KXmlGuiWindow and KGameBasicWindow. Do you think it should be offered as a compile-time or run-time option? (Obviously, this question depends on the open question above.)
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdegames/kdiamond/src/mainwindow.h 1239968 
>   /trunk/KDE/kdegames/kdiamond/src/mainwindow.cpp 1239968 
>   /trunk/KDE/kdegames/libkdegames/CMakeLists.txt 1239968 
>   /trunk/KDE/kdegames/libkdegames/includes/CMakeLists.txt 1239968 
>   /trunk/KDE/kdegames/libkdegames/includes/KGameBasicWindow PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kgamebasicwindow.h PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kgamebasicwindow.cpp PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kgamedifficulty.h 1239968 
>   /trunk/KDE/kdegames/libkdegames/kgamedifficulty.cpp 1239968 
> 
> Diff: http://svn.reviewboard.kde.org/r/6744/diff
> 
> 
> Testing
> -------
> 
> As usual, my guinea pig is KDiamond. The needed changes are included in this patch. Everything works fine here. (You might notice that I forgot setAutoSaveSettings() in kdiamond/src/mainwindow.cpp. That's fixed in my working copy.)
> 
> 
> Screenshots
> -----------
> 
> Side-by-side comparison of KXmlGuiWindow and KGameBasicWindow
>   http://svn.reviewboard.kde.org/r/6744/s/613/
> Overview of the different toolbar states; from top to bottom: main menu, settings menu, help menu
>   http://svn.reviewboard.kde.org/r/6744/s/614/
> 
> 
> Thanks,
> 
> Stefan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20110709/6e5d61fa/attachment.htm