[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Summary of last nights talk on irc
From:       Carsten Pfeiffer <carpdjih () cetus ! zrz ! TU-Berlin ! DE>
Date:       1999-08-24 11:31:27
[Download RAW message or body]

On Tue, Aug 24, 1999 at 10:24:00AM +0200, Matthias Elter wrote:

Hi,

> > Matthias, this is for you: We both strongly want to make KIS 16-bit based. At
> > least we should make it as easy as possible to port to 16-bit. KIS should be
> > 16-bit because this will be the standard in some time.
> 
> Yes, Andrew already managed to convince me about this with his template idea.

great :o)
  
> > Casten writes a global config class. All parameters have to be read from it and
> > must be written into it. Perhaps Carsten can mail some using instructions when
> > its finished.
> 
> Yes, we talked about this earlier, I second this.

Will do. I will make a little document and put it into the (to be created)
docs-directory on CVS and post it here.
 
A short summary of my design is:

there are two types of config-settings, global ones (e.g. font-settings,
keyboard accelerators, undo limitations, ...) and view-specific settings
(e.g. the current tool, current brush, current document, ...).

Every view creates an own object of the config-class and operates on it.
That way, it can use and modify its view-specific settings as it likes,
other views are not affected.
Global settings are static members and thus shared between all
config-objects. When changing a static member, a signal
globalConfigChanged() will be emitted, so the other views can update.
I'm not sure whether one signal is ok (every global setting would have to
be reread, then), or whether every setting should have an own signal.

All dialogs will get an own small config-class, e.g. BrushDlgConfig. When
a brush is changed, the brushes dialog will call something like
BrushDlgConfig::setBrush() which will emit a signal brushChanged().

So everyone interested in brushes does NOT communicate with the brushes
dialog, but with its config-class. Same goes for any other dialogs.
The dialog config-classes have to implement an interface for loading and
saving its settings, which will be called from the main config-class.

> > We want to create a docs directory in the kimageshop repository. There should
> > be file with references and all our design documents.
> 
> Yes, good idea, go ahead.

Will do, when zeus lets me :-/
 
> > The Undo/Redo-part has grow a bit. We decided not to make all commands undoable
> > (at least per default). Such commands as zooming should not be in undo list.
> > This should be adjustable in the preferences dialog.
> >
> > Each command that should be undoable will be derived from KImageShopCommand. It
> > shall only contain data for undo/redo, not the tool itself. A tool should add a
> > command to the command history.

I had in mind to have two separate undo-lists, one for image operations,
and one for operations, that don't affect image data (e.g. zooming, which
only affects the view, not the document). Such reversible operations could
be stored in a simple history, they're not _that_ important (but they are
quite easy to do, as only some parameters have to be stored).

Image operations are stored in a different list, which is accessible from
the history listbox (as already proposed).

Every image operation (be it a tool or a filter) should be derived from a
base class ImageOperation (or sth like that) which has an interface to the
undo-stuff, so not every filter has to care about that.
I think I wrote some stuff about that a while ago in my undo-thoughts.

I even suggest to make a second base-class ToolOperation based on
ImageOperation, which all tools inherit. All tools will have to
communicate with the statusbar, with some info-widget, maybe have custom
config-tabs in a common tooldialog, etc., so this would be the place to
make an interface for all that.

> > Carsten, any comments ? Do I forgot something ? You know, gelee ...

Hehe, just be careful before it becomes Wackelpudding (sorry, my
dictionary doesn't have that one, maybe it's wobble pudding?) :o)

Cheers,
Carsten Pfeiffer
-- 
http://www.geocities.com/SiliconValley/1632/

[prev in list] [next in list] [prev in thread] [next in thread]