tool activate()

[Boudewijn Rempt]

On Tuesday 22 March 2005 14:38, Casper Boemann wrote:
>
> > * Every tool must have a tool widget that is plugged into the control box
> >   (and, by the way, the widget shouldn't be wider than, say, 275 pixels,
> >   because I'm going to make a hard fixed width for all dockers.)
>
> It shouldn't be a requirement. I mean it should be ok for the tool to not
> have a control box.

But almost all tools should have a widget. Everything that paints has at least 
opacity -- other tools will want to show things like the dimensions of the 
current selection. In the interests of consistency, there should be 
something, no matter how simple.

> And the 275 pixel limit is a bit problematic as it depends on font size and
> screen size. But we need to limit it somehow.

It's a Qt problem. There's simply no other way to prevent the irritating size 
changes of a dock window when you select another widget.

> > * The design we made a month ago for the toolbox should be our guide for
> > the user interface; additionally, the control docker should have a tab
> > with a a frame for every pointer that shows its associated tool.
>
> wasn't that just the gui for paint op or did I miss something.
> The thing about tab in control dockes seems ok, as long as no tabs are
> visible when only a single pointer is attached.

A combination. You have the paint ops in an extensible QToolBox based 
interface, and the tools organized in paint tools (freehand, shape, filled 
shape), selection tools and canvas tools (crop, pan, zoom). The tools go into
a two-column or two-row QToolBar with small icons, as in Karbon.
 
> > I see no reason, judging from these points, to use the kxmlgui structure
> > with .rc files and KActions for our tools. Tools are not added to the
> > menu anyway, so there's only one place for the action to do its work.
>
> I think this is very dangerous. The transform tool I'm working on is in
> photoshop attached to a menu and I was considering to do the same as it
> could be said to belong to the edit menu.

A single plugin can be both; you can add a menu option that calls the tool and 
that is added for every view by kxmlgui, but the tool itself can be a module 
that is loaded on startup and that is added to the toolbox by the view (which 
queries the tool registry for existing tools).

> And though my reply might seem like a lot of OKs I'm worried that our
> thoughts of integrating tools and paintops might be limited by a quick
> design.
>
> Are paintops plugins? If not then they should be - shouldn't they?

They are already plugins. Currently, filters, paintops and tools are all 
plugins. Not yet plugins (but should become plugins) are autogradient, 
autotext, autobrush, color selectors and resources. (Have you ever taken a 
look at KisResourceMediator? 	It's very extensible, but only by copying and 
pasting...). 

> For now I think I'll commit the namechange from activate() to intro(). Is
> that ok?

I don't like the name "intro" much... It's not a verb, and not really 
descriptive. But if you want to get something descriptive, things like
"makeActive" or "init(ialize)" crop up. Maybe just "begin"?

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050322/fb8746ab/attachment.pgp