<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://svn.reviewboard.kde.org/r/6744/">http://svn.reviewboard.kde.org/r/6744/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On July 10th, 2011, 2:26 a.m., <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Had a look at your code, Stefan. My C++ is not as fluent as yours, but I wonder if it would be possible to polymorphise the view layer, with toolbar as a default type, but leaving the way open to add other view types, such as paged menus or button boxes. If so, one should be able to specify a view type for each group, rather than using the same for all groups, and that would go a long way towards providing the kinds of user interfaces mobile devices typically have. Just a thought.</pre>
</blockquote>
<p>On July 10th, 2011, 6:06 p.m., <b>Stefan Majewsky</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Definitely possible, as the API makes no assumption about the type of view for the action groups at this point (although the documentation does). I can add an enumeration of available view types (with ToolBar being the only entry for this first iteration) and require a value from this enumeration as additional argument to addGroup().</pre>
</blockquote>
<p>On July 11th, 2011, 1:08 p.m., <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Sounds good. What do others think? And are the Plasma guys doing anything like this?
Presumably toolbar would be the default value for addGroup(). Would an enumeration lead to binary or source code incompatibility as it is added to? Is there any other way to make KGameBasicWindow extensible?</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Re Plasma: Will try to find the relevant Plasma people at the Desktop Summit next month.
Re compatibility: Adding to an enum is compatible in all directions, with the obvious exception that programs compiled to use enum values introduced in version X are not backwards-compatible to anything before X. What's forbiddden, though, is to modify the integer values of enumerated constants (e.g. changing "enum X { Foo = 1 };", to "enum X { Foo = 2 };"), because the symbolic names are lost during the compilation.</pre>
<br />
<p>- Stefan</p>
<br />
<p>On July 9th, 2011, 6:53 p.m., Stefan Majewsky wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://svn.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for KDE Games and usability.</div>
<div>By Stefan Majewsky.</div>
<p style="color: grey;"><i>Updated July 9, 2011, 6:53 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.
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.)</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">As usual, my guinea pig is KDiamond. The needed changes are included in this patch. Everything works fine here.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/trunk/KDE/kdegames/kdiamond/src/mainwindow.h <span style="color: grey">(1240604)</span></li>
<li>/trunk/KDE/kdegames/kdiamond/src/mainwindow.cpp <span style="color: grey">(1240604)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/CMakeLists.txt <span style="color: grey">(1240604)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/includes/CMakeLists.txt <span style="color: grey">(1240604)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/includes/KGameBasicWindow <span style="color: grey">(PRE-CREATION)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/kgamebasicwindow.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/kgamebasicwindow.cpp <span style="color: grey">(PRE-CREATION)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/kgamedifficulty.h <span style="color: grey">(1240604)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/kgamedifficulty.cpp <span style="color: grey">(1240604)</span></li>
</ul>
<p><a href="http://svn.reviewboard.kde.org/r/6744/diff/" style="margin-left: 3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Screenshots </h1>
<div>
<a href="http://svn.reviewboard.kde.org/r/6744/s/616/"><img src="http://svn.reviewboard.kde.org/media/uploaded/images/2011/07/09/kgbw2_1_400x100.png" style="border: 1px black solid;" alt="Side-by-side comparison of KXmlGuiWindow (back) and KGameBasicWindow (front) for KDiamond" /></a>
<a href="http://svn.reviewboard.kde.org/r/6744/s/617/"><img src="http://svn.reviewboard.kde.org/media/uploaded/images/2011/07/09/kgbw3_400x100.png" style="border: 1px black solid;" alt="Overview of available toolbar states for KDiamond: main category, Settings subcategory, Help subcategory" /></a>
</div>
</td>
</tr>
</table>
</div>
</body>
</html>