Commit 6b768de7 authored by Halla Rempt's avatar Halla Rempt
Browse files

Bit of dox updating & fixing the api for option widgets.

svn path=/trunk/koffice/; revision=600526
parent f8fd5df5
......@@ -41,6 +41,9 @@ class KoShape;
* <p>The using application can intantiate this class and add its canvas using the
* setCanvas() call. Which is designed so it can be called multiple times for those
* that wish to exchange one canvas widget for another.
* Effectively, there is _one_ KoCanvasController per KoView in your application.
class FLAKE_EXPORT KoCanvasController : public QScrollArea {
......@@ -70,21 +70,15 @@ void KoTool::useCursor(QCursor cursor, bool force) {
QWidget * KoTool::optionWidget(QWidget * parent) {
if ( !m_optionWidget ) {
// XXX: Re-add the ui tool name to show in this label. It probably
// was removed post moving KisTool to KoTool and I'm too fed up
// to re-add it right now. (boud)
// TZ: On the other hand, just returning any widget here will loose the
// information whether we actually have options or not. I'd much rather
// return 0 if there are no options and let the GUI show a better default.
// Especially since I expect to have an interface soon where we can extract
// the options from the option-panel instance and persist them between restarts.
//m_optionWidget = new QLabel(i18n("No options for %1.", m_visibleName), parent);
QLabel * l = new QLabel(i18n("No options for the current tool"), parent);
m_optionWidget = l;
// Create the optionwidget if it doesn't exist yet
if (m_optionWidget == 0) {
// If there is an optionwidget, but it is owned by a different widget,
// reparent. Note: is setParent correct here, or should I use reParent?
// The Qt dox are not conclusive.
if (m_optionWidget != 0 && m_optionWidget->parent() != parent) {
return m_optionWidget;
......@@ -37,8 +37,13 @@ class QWidget;
class QPainter;
* Abstract base class for all tools that manipulate flake objects.
* Abstract base class for all tools. Tools can create or manipulate
* flake shapes, canvas state or any other thing that a user may wish
* to do to his document or his view on a document with a pointing
* device.
* There exists an instance of every tool for every pointer device.
* These instances are managed by the toolmanager..
class FLAKE_EXPORT KoTool : public QObject
......@@ -104,9 +109,10 @@ public:
* Return the option widget for this tool. Create it if it
* does not exist yet.
* does not exist yet. If the tool does not have an option widget,
* this method return 0. (After discussion with Thomas, who prefers
* the toolmanager to handle that case.)
* Note: by default an empty widget is created.
* @see m_optionWidget
virtual QWidget * optionWidget(QWidget * parent);
......@@ -209,14 +215,23 @@ protected:
* @param force if true the cursor will be set no matter what.
void useCursor(QCursor cursor, bool force=false);
* Reimplement this if your tool actually has an option widget.
* Sets the option widget to 0 by default.
virtual void createOptionWidget(QWidget * parent) { m_optionWidget = 0; }
KoCanvasBase *m_canvas; ///< the canvas interface this tool will work for.
QWidget * m_optionWidget; ///< the optionwidget this tool will show in the option widget palette
KoTool(const KoTool&);
KoTool& operator=(const KoTool&);
QCursor m_previousCursor;
QWidget * m_optionWidget;
#endif /* KOTOOL_H */
......@@ -70,7 +70,8 @@ class KoShape;
* KoToolManager also keeps track of the current tool based on a
complex set of conditions and heuristics:
- there is one active tool per canvas
- there is one active tool per KoCanvasController (and there is one KoCanvasController
per view, because this is a class with scrollbars and a zoomlevel and so on)
- for every pointing device (determined by the unique id of tablet,
or 0 for mice -- you may have more than one mouse attached, but
Qt cannot distinquish between them, there is an associated too.
......@@ -85,7 +86,6 @@ class KoShape;
longer interesting to you which tool is active; you can safely
route the paint event through KoToolManager::paint().
(The reason the input events are handled completely by the
toolmanager and the paint events not is that, generally speaking,
it's okay if the tools get the input events first, but you want to
......@@ -31,6 +31,7 @@ KoToolRegistry::KoToolRegistry() {
const KService::List offers = KServiceTypeTrader::self()->query(
QString::fromLatin1("(Type == 'Service') and ([X-Flake-Version] == 1)"));
kDebug(30008) << "KoToolRegistry searching for plugins, " << offers.count() << " found\n";
foreach(KService::Ptr service, offers) {
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment