Tools

[Patrick Julien]

> So I'd say, let the parts idea ripen, and in the meantime let's have at
> least one decent brush. A brush tests: colours, gradients, patterns,
> brushes, compositing, interactive performance, undo/redo, user interface --
> that should keep the rest of Krita on the straight and narrow.

Okay.  I'll finish up the ClipboardMgr and memento and leave tools statically 
linked in for now.  Since the last commit, encapsulation is good enough now 
that they can be ripped out when the times come.

>
> > You had many gripes about the ui of Krita, if you feel like making
> > improvements there, it might be a better investement for the next week or
> > so.
>
> Yes, well, I think Krita doesn't look very attractive right now, but I
> really want that brush :-). On the other hand, a nice and glitzy interface
> would help, too. I'll see what grabs me next. Isn't there something in KDE
> that loads .ui files and creates a dialog dynamically -- that would help
> with the dialog designs, and especially with the tool properties dialogs.

Qt Designer.  Qt Designer has really come a long way but still has some 
annoyances but nothing really serious.  Just make sure you have all the kde 
widgets registered tho, i.e. you want to use KDialog, not QDialog in the 
designer an so on.

>
> > So, basically, after tonight, I still have the ClipboardMgr thing, tool
> > memento and dynamically load them.
>
> Life is so easy with GNUStep or OS X as far as dynamic loading of things
> like tools is concerned. Or even with Java. Just make a bundle, or an
> archive that contains the code, the definitions for the user interface and
> the relevant artwork. I've read the various kparts tutorials, but I'm not
> sure how the packaging of all these bits is handled -- and most of them are
> about adding a new view, while we need only one pesky icon in a toolbox, a
> dialog and then need to interact with the current view.

It's actually very similar, however, you're mixing up components and libraries 
that you would load dynamically.   OpenStep style bundles actually are more 
similar to libraries, not parts.

Components have better encapsulation and more features that allows their 
embedding in several applications without actually knowing what you're 
playing with.  They are also brokered centrally.  Making a shared library 
that we just use QLibrary to load would almost be identical to what you would 
do on GNUStep or OSX.  Here, we are using components, so it's a little more 
complicated at first but you get more features and management out of it in 
the long run.