[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Review Request: KOffice UI Abstraction
From: "Jaroslaw Staniek" <staniek () kde ! org>
Date: 2010-10-14 12:59:27
Message-ID: 20101014125927.16820.80236 () vidsolbach ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On 2010-10-14 12:12:50, Jaroslaw Staniek wrote:
> > branches/work/koffice-essen/tools/f-office/KoAbstractApplicationController.cpp, \
> > line 216 <http://svn.reviewboard.kde.org/r/5615/diff/1/?file=39247#file39247line216>
> >
> > Boud, do you mean this line should be replaced by something other?
>
> Boudewijn Rempt wrote:
> In general, yes, but that's a bigger undertaking. With the advent of the \
> graphicsview compatibility, we can do without KoView and subclasses completely -- \
> so in the end, there's no reason to query the view for its canvacontroller widget \
> children since you don't necessarily have a view.
> The way I see KoView in koffice is like this: it provides the gui decorations \
> (toolbars, dockers, menubars) around one or more canvas widgets. If we have a \
> different ui, we should be able to do without the KoView completely.
> That's why KoDocument either creates a view or creates a canvas item.
OK. Also being independent of KXMLGUI would be good thing.
- Jaroslaw
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5615/#review8150
-----------------------------------------------------------
On 2010-10-13 08:16:29, Jaroslaw Staniek wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5615/
> -----------------------------------------------------------
>
> (Updated 2010-10-13 08:16:29)
>
>
> Review request for KOffice.
>
>
> Summary
> -------
>
> KOffice UI Abstraction enables implementing various UIs on top of KOffice without \
> in-depth knowledge of KOffice MVC APIs. It's in par with efforts of making KOffice \
> not dependent on QWidget-based interfaces (currently in koffice-essen branch).
> It's effect of rather careful code cleanup and refactoring. Published for review as \
> early as possible. The target is 2.4.
> Status: FreOffice works as before
>
> Changes, features:
> * KoAbstractApplicationController introduced - it is mostly abstract controller \
> having only generic code and logic that would stay the same regardless of the UI \
> and workflow implementation
> * Inheritance tree for MainWindow in case of FreOffice:
> KoAbstractApplicationController <----\
> KoAbstractApplication <---- MainWindow
> QMainWindow <------------------------/
>
> Indirection in KoAbstractApplicationImpl.h was needed to enable inheriting from any \
> QObject-derived class the main window (MOC does not support templates affecting \
> inheritance tree nor multiple inheritance from QObject). In case of FreOffice it is \
> QMainWindow but in other cases it could be e.g. QGraphicsView.
> So KoAbstractApplicationController is not a QObject. Technically, \
> KoAbstractApplication is a thin layer that is compiled into MainWindow (or any \
> other implementation) and mostly translates raw methods (abstracted \
> KoAbstractApplicationController) into slots, so UI developer can connect own \
> actions directly to these slots. Compiling-in is performed by using \
> KoAbstractApplicationBase typedef.
> The design is more complex internally but makes live simpler for users of the \
> public API.
> * void KoAbstractApplicationController::showMessage(KoAbstractApplication::MessageType \
> type, const QString& messageText = QString()) added; used instead of direct calls \
> to QMessageBox or custom QDialogs; this cleans up MainWindow.cpp a lot, and removes \
> #ifdefs; MessageType can be currently UnsupportedFileTypeMessage, \
> InformationMessage (on maemo it's with default timeout), \
> InformationWithoutTimeoutMessage (without timeout). Optional messageText is \
> provided so abstraction itself can define common messages in typical cases (with \
> i18n) so UI implementation would not have to do the same again and again. Improves \
> consistency. There are no changes in behaviour in FreOffice.
> * Dialog "Document is modified, do you want to save it before closing?" moved from \
> global-within-MainWindow code to separate ConfirmationDialog, implementation left \
> as is, specific to FreOffice, abstracted as UnsupportedFileTypeMessage in \
> showMessage()
> * Similarly to showMessage(), virtual QMessageBox::StandardButton \
> askQuestion(QuestionType type, const QString& messageText = QString()) is added \
> currently supporting SaveDiscardCancelQuestion, ConfirmSheetDeleteQuestion.
> * abstractions of file dialogs added: showGetOpenFileNameDialog(), \
> showGetSaveFileNameDialog(); FreOffice uses QFileDialogs here
> * virtual keyboard is expected to be provided by the given UI implementation, \
> abstraction defines setVirtualKeyboardVisible(bool) and isVirtualKeyboardVisible(); \
> this allows to use system virtual keyboard if possible and if needed
> * transition from editing to view mode and back is handled by abstraciton bool \
> setEditingMode(bool)
> * moving across pages and slides is handled by goToNextSlide(), goToNextPage(), \
> etc.; additional reaction to changing page can be implemented by UIs in \
> currentPageChanged()
> * there was attempt to hide KoDocument and KoView and Ko*Controller pointers in the \
> abstractions (setDocumentModified() was provided for example); for now these are \
> still needed; when hidden completely the API will be less complex error prone and \
> prone to regressions when something changes in the kolibs
> * document-related methods are ready to use in the UIs as closeDocument(), \
> saveDocument(), saveDocumentAs(), openDocument()
> * tracking ko tool changes is handled in abstraction too (activeToolChanged()); \
> always behaves as in FreOffice for now, i.e. limits set of tools only to these \
> available in the UI; pointers to all internal flake tools are kept in the \
> abstraction
> * abstraction specific to document type is provided, e.g. slide* methods mentioned \
> earlier, addSheet(), removeSheet() for kspread.
> * code of PreviewWindow and StoreButtonPreview improved a bit
>
> * markup in AboutDialog fixed
>
> * automoc is used via kde4_add_executable for consistency (also required because \
> KoAbstractApplication.moc cannot be built on its own as there's typedef)
> * f-office/CMakeLists.txt cleaned up: instead of copy-paste of file lists, \
> list(APPEND ...) is used; the code builds also on systems without OpenGL enabled
> Current TODOs are:
> * abstracting more features, e.g. searching, formatting
> * move the abstraction to separate libkoabstraction in libs/koabstraction/, leaving \
> only MainWindow implementation and specific UIs in f-office
> * use CollaborateInterface so code that calls collaboration can be in abstraction \
> itself
> * later: add proof of concept minimal usage example for TechBase
> * in addition even inheriting just from QObject could be possible if we remove a \
> few dynamic_casts to QWidget; for now QWidget is the minimum for \
> the main window.
> * make move defines from Common.h internal within abstraction, as has been done \
> with FILE_CHOOSER_FILTER
>
> Diffs
> -----
>
> branches/work/koffice-essen/tools/f-office/AboutDialog.cpp 1185212
> branches/work/koffice-essen/tools/f-office/CMakeLists.txt 1185212
> branches/work/koffice-essen/tools/f-office/CollaborateInterface.h PRE-CREATION
> branches/work/koffice-essen/tools/f-office/Common.h 1185212
> branches/work/koffice-essen/tools/f-office/ConfirmationDialog.h PRE-CREATION
> branches/work/koffice-essen/tools/f-office/ConfirmationDialog.cpp PRE-CREATION
> branches/work/koffice-essen/tools/f-office/KoAbstractApplication.h PRE-CREATION
> branches/work/koffice-essen/tools/f-office/KoAbstractApplicationController.h \
> PRE-CREATION branches/work/koffice-essen/tools/f-office/KoAbstractApplicationController.cpp \
> PRE-CREATION branches/work/koffice-essen/tools/f-office/KoAbstractApplicationImpl.h \
> PRE-CREATION branches/work/koffice-essen/tools/f-office/KoAbstractApplicationImpl.cpp \
> PRE-CREATION branches/work/koffice-essen/tools/f-office/MainWindow.h 1185212
> branches/work/koffice-essen/tools/f-office/MainWindow.cpp 1185212
> branches/work/koffice-essen/tools/f-office/OfficeInterface.h 1185212
> branches/work/koffice-essen/tools/f-office/PreviewDialog.h 1185212
> branches/work/koffice-essen/tools/f-office/PreviewDialog.cpp 1185212
>
> Diff: http://svn.reviewboard.kde.org/r/5615/diff
>
>
> Testing
> -------
>
> FreOffice works as before, possible minor regression, I am open to help fix them.
>
>
> Thanks,
>
> Jaroslaw
>
>
[Attachment #5 (text/html)]
<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/5615/">http://svn.reviewboard.kde.org/r/5615/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On October 14th, 2010, 12:12 p.m., <b>Jaroslaw \
Staniek</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; \
border-collapse: collapse; margin: 2px padding: 2px;"> <thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; \
font-size: 9pt; padding: 4px 8px; text-align: left;"> <a \
href="http://svn.reviewboard.kde.org/r/5615/diff/1/?file=39247#file39247line216" \
style="color: black; font-weight: bold; text-decoration: \
underline;">branches/work/koffice-essen/tools/f-office/KoAbstractApplicationController.cpp</a>
<span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: 0; \
"></pre></td> <td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: \
0; ">bool KoAbstractApplicationController::openDocument(const QString &fileName, \
bool isNewDocument)</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2"></font></th> <td bgcolor="#c5ffc4" width="50%"><pre \
style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td> <th \
bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid \
#C0C0C0;" align="right"><font size="2">216</font></th> <td bgcolor="#c5ffc4" \
width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span \
class="n">QList</span><span class="o"><</span><span \
class="n">KoCanvasControllerWidget</span><span class="o">*></span> <span \
class="n">controllers</span> <span class="o">=</span> <span \
class="n">m_view</span><span class="o">-></span><span \
class="n">findChildren</span><span class="o"><</span><span \
class="n">KoCanvasControllerWidget</span><span class="o">*></span><span \
class="p">();</span></pre></td> </tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Boud, do you mean this \
line should be replaced by something other?</pre> </blockquote>
<p>On October 14th, 2010, 12:18 p.m., <b>Boudewijn Rempt</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;">In general, yes, but \
that's a bigger undertaking. With the advent of the graphicsview compatibility, \
we can do without KoView and subclasses completely -- so in the end, there's no \
reason to query the view for its canvacontroller widget children since you don't \
necessarily have a view.
The way I see KoView in koffice is like this: it provides the gui decorations \
(toolbars, dockers, menubars) around one or more canvas widgets. If we have a \
different ui, we should be able to do without the KoView completely.
That's why KoDocument either creates a view or creates a canvas item.</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">OK. Also \
being independent of KXMLGUI would be good thing.</pre> <br />
<p>- Jaroslaw</p>
<br />
<p>On October 13th, 2010, 8:16 a.m., Jaroslaw Staniek wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://svn.reviewboard.kde.orgrb/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 KOffice.</div>
<div>By Jaroslaw Staniek.</div>
<p style="color: grey;"><i>Updated 2010-10-13 08:16:29</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;">KOffice UI Abstraction enables implementing various UIs on top of \
KOffice without in-depth knowledge of KOffice MVC APIs. It's in par with efforts \
of making KOffice not dependent on QWidget-based interfaces (currently in \
koffice-essen branch).
It's effect of rather careful code cleanup and refactoring. Published for review \
as early as possible. The target is 2.4.
Status: FreOffice works as before
Changes, features:
* KoAbstractApplicationController introduced - it is mostly abstract controller \
having only generic code and logic that would stay the same regardless of the UI and \
workflow implementation
* Inheritance tree for MainWindow in case of FreOffice:
KoAbstractApplicationController <----\
KoAbstractApplication <---- MainWindow
QMainWindow <------------------------/
Indirection in KoAbstractApplicationImpl.h was needed to enable inheriting from any \
QObject-derived class the main window (MOC does not support templates affecting \
inheritance tree nor multiple inheritance from QObject). In case of FreOffice it is \
QMainWindow but in other cases it could be e.g. QGraphicsView.
So KoAbstractApplicationController is not a QObject. Technically, \
KoAbstractApplication is a thin layer that is compiled into MainWindow (or any other \
implementation) and mostly translates raw methods (abstracted \
KoAbstractApplicationController) into slots, so UI developer can connect own actions \
directly to these slots. Compiling-in is performed by using KoAbstractApplicationBase \
typedef.
The design is more complex internally but makes live simpler for users of the public \
API.
* void KoAbstractApplicationController::showMessage(KoAbstractApplication::MessageType \
type, const QString& messageText = QString()) added; used instead of direct calls \
to QMessageBox or custom QDialogs; this cleans up MainWindow.cpp a lot, and removes \
#ifdefs; MessageType can be currently UnsupportedFileTypeMessage, InformationMessage \
(on maemo it's with default timeout), InformationWithoutTimeoutMessage (without \
timeout). Optional messageText is provided so abstraction itself can define common \
messages in typical cases (with i18n) so UI implementation would not have to do the \
same again and again. Improves consistency. There are no changes in behaviour in \
FreOffice.
* Dialog "Document is modified, do you want to save it before closing?" \
moved from global-within-MainWindow code to separate ConfirmationDialog, \
implementation left as is, specific to FreOffice, abstracted as \
UnsupportedFileTypeMessage in showMessage()
* Similarly to showMessage(), virtual QMessageBox::StandardButton \
askQuestion(QuestionType type, const QString& messageText = QString()) is added \
currently supporting SaveDiscardCancelQuestion, ConfirmSheetDeleteQuestion.
* abstractions of file dialogs added: showGetOpenFileNameDialog(), \
showGetSaveFileNameDialog(); FreOffice uses QFileDialogs here
* virtual keyboard is expected to be provided by the given UI implementation, \
abstraction defines setVirtualKeyboardVisible(bool) and isVirtualKeyboardVisible(); \
this allows to use system virtual keyboard if possible and if needed
* transition from editing to view mode and back is handled by abstraciton bool \
setEditingMode(bool)
* moving across pages and slides is handled by goToNextSlide(), goToNextPage(), etc.; \
additional reaction to changing page can be implemented by UIs in \
currentPageChanged()
* there was attempt to hide KoDocument and KoView and Ko*Controller pointers in the \
abstractions (setDocumentModified() was provided for example); for now these are \
still needed; when hidden completely the API will be less complex error prone and \
prone to regressions when something changes in the kolibs
* document-related methods are ready to use in the UIs as closeDocument(), \
saveDocument(), saveDocumentAs(), openDocument()
* tracking ko tool changes is handled in abstraction too (activeToolChanged()); \
always behaves as in FreOffice for now, i.e. limits set of tools only to these \
available in the UI; pointers to all internal flake tools are kept in the abstraction
* abstraction specific to document type is provided, e.g. slide* methods mentioned \
earlier, addSheet(), removeSheet() for kspread.
* code of PreviewWindow and StoreButtonPreview improved a bit
* markup in AboutDialog fixed
* automoc is used via kde4_add_executable for consistency (also required because \
KoAbstractApplication.moc cannot be built on its own as there's typedef)
* f-office/CMakeLists.txt cleaned up: instead of copy-paste of file lists, \
list(APPEND ...) is used; the code builds also on systems without OpenGL enabled
Current TODOs are:
* abstracting more features, e.g. searching, formatting
* move the abstraction to separate libkoabstraction in libs/koabstraction/, leaving \
only MainWindow implementation and specific UIs in f-office
* use CollaborateInterface so code that calls collaboration can be in abstraction \
itself
* later: add proof of concept minimal usage example for TechBase
* in addition even inheriting just from QObject could be possible if we remove a few \
dynamic_casts to QWidget; for now QWidget is the minimum for the main \
window.
* make move defines from Common.h internal within abstraction, as has been done with \
FILE_CHOOSER_FILTER </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;">FreOffice works as before, possible minor regression, I am open to help \
fix them.</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>branches/work/koffice-essen/tools/f-office/AboutDialog.cpp <span style="color: \
grey">(1185212)</span></li>
<li>branches/work/koffice-essen/tools/f-office/CMakeLists.txt <span style="color: \
grey">(1185212)</span></li>
<li>branches/work/koffice-essen/tools/f-office/CollaborateInterface.h <span \
style="color: grey">(PRE-CREATION)</span></li>
<li>branches/work/koffice-essen/tools/f-office/Common.h <span style="color: \
grey">(1185212)</span></li>
<li>branches/work/koffice-essen/tools/f-office/ConfirmationDialog.h <span \
style="color: grey">(PRE-CREATION)</span></li>
<li>branches/work/koffice-essen/tools/f-office/ConfirmationDialog.cpp <span \
style="color: grey">(PRE-CREATION)</span></li>
<li>branches/work/koffice-essen/tools/f-office/KoAbstractApplication.h <span \
style="color: grey">(PRE-CREATION)</span></li>
<li>branches/work/koffice-essen/tools/f-office/KoAbstractApplicationController.h \
<span style="color: grey">(PRE-CREATION)</span></li>
<li>branches/work/koffice-essen/tools/f-office/KoAbstractApplicationController.cpp \
<span style="color: grey">(PRE-CREATION)</span></li>
<li>branches/work/koffice-essen/tools/f-office/KoAbstractApplicationImpl.h <span \
style="color: grey">(PRE-CREATION)</span></li>
<li>branches/work/koffice-essen/tools/f-office/KoAbstractApplicationImpl.cpp <span \
style="color: grey">(PRE-CREATION)</span></li>
<li>branches/work/koffice-essen/tools/f-office/MainWindow.h <span style="color: \
grey">(1185212)</span></li>
<li>branches/work/koffice-essen/tools/f-office/MainWindow.cpp <span style="color: \
grey">(1185212)</span></li>
<li>branches/work/koffice-essen/tools/f-office/OfficeInterface.h <span style="color: \
grey">(1185212)</span></li>
<li>branches/work/koffice-essen/tools/f-office/PreviewDialog.h <span style="color: \
grey">(1185212)</span></li>
<li>branches/work/koffice-essen/tools/f-office/PreviewDialog.cpp <span style="color: \
grey">(1185212)</span></li>
</ul>
<p><a href="http://svn.reviewboard.kde.org/r/5615/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic