[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Disabling of tools
From: Thomas Zander <zander () kde ! org>
Date: 2008-10-12 9:35:04
Message-ID: 200810121135.04624.zander () kde ! org
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
[Attachment #4 (multipart/mixed)]
On Sunday 12. October 2008 10:47:39 Cyrille Berger wrote:
> On Sunday 12 October 2008, Thomas Zander wrote:
> > Currently the only way you can loose your tools is if you manually go
> > to the layer box and select a shape layer.
>
> Or use the vector freehand tool:
> The users that reported the issue were first using the karbon freehand
> tool which creates a shape layer which made the tool disappeared which
> made them think that there is a bug.
Ahh, yes, I went one step too fast, apologies :)
My idea is that when the user is working in Krita, on a normal pixel layer,
he will not see the irrelevant tools.
This means that the default tool would be gone, as its just sitting there
and has no function. This also means that the freehand tool would not be
visible there either. In effect you will have the krita toolbar you knew
from 1.x
This solves a lot of problems and I brought it up in this thread because it
does have a big effect on the problem you were having.
For clarity let me reiterate the idea I was trying to explain. Please let me
know if its clear and you just disagree, or if its just not clear ;)
In the koffice2 concept we make the GUI highly adaptive based on the current
task at hand.
In KWord/Karbon/etc we decide what the user does based on the selected
shape(s). And we can do that in Krita too, but we need something a bit
larger as well for krita. So I suggest we use layers for that.
When the user activates a shape layer in essence the toolbox will be exactly
like it is in karbon/kword. Which means it will show the default tool, the
gradient tool and the dynamic tools like the text tool. No krita tools.
When the user activates a krita pixel layer the toolbox will in essence look
like it did in Krita 1. Meaning no default tool, no vector creation tool
and all the pixel tools.
The direct differences are;
* The layer tool will be more important for the user if he wants to
integrate shape and pixel layers.
* The user will not see the freehand tool or gradient tool until he created
a shape layer and selected it.
I realize this means less discoverable, but as you pointed out there are
various problems otherwise. I think the reason for the confusion is because
we try to make similar two completely separate concepts. Editing shapes and
editing pixel layers just are not that similar.
* The toolbox will be smaller because the useless tools are not visible. I
think this will make things appear less overwhelming.
* Krita would totally follow the koffice-wide interaction rules in regards
to the toolbox, which means more consistency and happier users ;)
* Tools are removed from the toolbox when they are not useful. So we won't
see tools that can't work in the toolbox.
* When the current layer is not editable (or visible) the whole toolbox is
disabled, this is a toolbox property and not a per-tool property.
Now, these last two points are important as this means that your suggestion
to extend the tools concept with an 'isEnabled()' flag is not needed.
We just reuse the already existing concept of hiding the tools when they can
not be used.
> Well anyway, it's completely unrelated to the matter at hand, so if you
> wish to discuss this further, I suggest starting a new thread or opening
> a bug report.
>
> > > It's also less flexible,
> > > a tool can also be disabled if there is no perspective grid, or no
> > > whatever else. While preventing the tool to cheat sounds like a good
> > > idea, I somehow think that it is the tool that know best their
> > > requirement.
> >
> > My suggestion to massively disable tools under certain logical
> > circumstances is mean to avoid code duplication.
Note that when I said 'disable' above, I actually meant that they should be
removed from the toolbox. Apologies for the confusion.
> > It doesn't take away from the tools ability to conclude it can't be
> > used at this time. So it won't be less flexible at all, just that more
> > generic work will be done without code in each and every tool.
>
> Ok so we would have the setEnabled mechanism in KoTool to disable the
> tools. And a mechanism in KoToolManager that would call
> KoTool::setEnabled for a "massive" disabling/enabling of tools, and that
> would be connect to a change of layer triggered by a signal comming from
> the shape manager's selection ?
If we were to use the current layer then all that is needed is something
like the attached mockup-patch.
So, no, a disabled flag would be unneeded and listening to the selection is
also not needed, just the current layer :)
> Voila http://bugs.kde.org/show_bug.cgi?id=172642 ;)
Thanks!
I suspect that this bug will be fixed automatically would the above
suggestion be implemented ;)
--
Thomas Zander
["currentlayer.diff" (text/x-diff)]
diff --git a/libs/flake/KoSelection.cpp b/libs/flake/KoSelection.cpp
index b8e4d37..5791a26 100644
--- a/libs/flake/KoSelection.cpp
+++ b/libs/flake/KoSelection.cpp
@@ -295,6 +295,7 @@ KoShape *KoSelection::firstSelectedShape(KoFlake::SelectionType \
strip) const void KoSelection::setActiveLayer(KoShapeLayer* layer)
{
d->activeLayer = layer;
+ emit currentLayerChanged(layer);
}
KoShapeLayer* KoSelection::activeLayer() const
diff --git a/libs/flake/KoSelection.h b/libs/flake/KoSelection.h
index d881c24..86a6a57 100644
--- a/libs/flake/KoSelection.h
+++ b/libs/flake/KoSelection.h
@@ -140,6 +140,9 @@ signals:
/// emitted when the selection is changed
void selectionChanged();
+ /// emitted when the current layer is changed
+ void currentLayerChanged(const KoShapeLayer *layer);
+
private:
virtual void saveOdf(KoShapeSavingContext &) const;
virtual bool loadOdf(const KoXmlElement &, KoShapeLoadingContext &);
diff --git a/libs/guiutils/KoToolBox.cpp b/libs/guiutils/KoToolBox.cpp
index d5af937..578c8b1 100644
--- a/libs/guiutils/KoToolBox.cpp
+++ b/libs/guiutils/KoToolBox.cpp
@@ -336,6 +336,8 @@ KoToolBox::KoToolBox(KoCanvasController *canvas)
connect(KoToolManager::instance(), SIGNAL(changedTool(const KoCanvasController*, \
int)), this, SLOT(setActiveTool(const KoCanvasController*, int)));
+ connect(KoToolManager::instance(), SIGNAL(currentLayerChanged(const \
KoShapeLayer*)), + this, SLOT(setCurrentLayer(const KoShapeLayer*)));
connect(KoToolManager::instance(), SIGNAL(toolCodesSelected(const \
KoCanvasController*, QList<QString>)),
this, SLOT(setButtonsVisible(const KoCanvasController*, \
QList<QString>))); }
@@ -391,6 +393,12 @@ void KoToolBox::setButtonsVisible(const KoCanvasController \
*canvas, const QList< }
}
+void KoToolBox::setCurrentLayer(KoShapeLayer *layer)
+{
+ const bool enabled = layer == 0 || layer->isEditable() && layer->isVisble();
+ // TODO iterate over all buttons and call setEnabled(enabled) on them;
+}
+
void KoToolBox::setCanvas(KoCanvasBase *canvas) {
d->canvas = canvas;
}
diff --git a/libs/guiutils/KoToolBox.h b/libs/guiutils/KoToolBox.h
index 0defb1c..17e5963 100644
--- a/libs/guiutils/KoToolBox.h
+++ b/libs/guiutils/KoToolBox.h
@@ -33,6 +33,7 @@ class QToolButton;
class ToolArea;
class KoCanvasController;
class KoCanvasBase;
+class KoShapeLayer;
/**
* KoToolBox is a dock widget that can order tools according to type and
@@ -92,6 +93,9 @@ public slots:
/// reimplemented from KoCanvasObserver
virtual void setCanvas(KoCanvasBase *canvas);
+private slots:
+ void setCurrentLayer(KoShapeLayer*);
+
protected:
void paintEvent(QPaintEvent *event);
["signature.asc" (application/pgp-signature)]
_______________________________________________
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