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

List:       kde-kimageshop
Subject:    Re: koffice/krita/image
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2008-11-02 14:03:47
Message-ID: 200811021503.48228.boud () valdyas ! org
[Download RAW message or body]

On Sunday 02 November 2008, Cyrille Berger wrote:
> On Sunday 02 November 2008, Boudewijn Rempt wrote:
> > For now, if it fixes things and doesn't break any, it's ok.
>
> Yeah, that's the "breaking" part that annoys me :) The other solution would
> be to call setDirty() in the plugins that do the conversion... but that
> would be dirty ;) 

Well, actually, one problem I found in 1.6 was that the image library handled 
the dirty-marking itself in a lot of cases, but not in all, and that it turned 
out to be impossible to reliably automate the dirty-setting so "client code" 
wouldn't have to worry about dirty marking. So my intention was to force the 
client to do the dirty marking.

> The problem is that when the signal is blocked the image
> isn't tell anymore that its layers have been modified, so in case we notice
> problem introduced by that change maybe a solution would be to detect at
> unlocking that the projection have been updated and then emit the correct
> signal.

Another problem here is that we tell the node, not the image that a node is 
dirtied. This makes it very hard, perhaps even impossible, with the current 
redisplay approach to multi-thread the recomposition code. This is one area 
where I think I'll have to do some refactoring for 2.1. 

But as I said, if this commit fixes things for 2.0 without breaking, it's 
fine.
-- 
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]