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

List:       koffice-devel
Subject:    Flake / KOfficeUI usage of KoID.
From:       Thomas Zander <zander () kde ! org>
Date:       2006-06-12 12:28:31
Message-ID: 200606121428.32506.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


I don't want to surprise everyone by just committing a design change in 
koffice-libs svn where the original design came from krita; since flake 
will reach everyone. So I will give my well thought out reasons here.
The short short version is; After working with the KoID for several more 
days I decided to stop using it in the above mentioned projects. Only the 
factory shall return it, but thats just to stay compatible and I don't 
think its a good design to keep it even there.

Requirements;
* There is a need for a Tool and a Shape class to be registered and other 
classes need to access it. We need an identification for that.
* The GUI needs various ways to show icons/strings
Examples:  A tool must be able to point to another tool for him to take 
over; that pointing is done using some form of ID.
Another example; a Tool can be specifically addressing a certain type of 
shape. For that the tool must identify that shape by its ID.
Last example; a tool that is a general tool should be able to specify it 
does not return a valid ID.

At this point; the most important part of plugins, loose coupling, breaks 
down.  Looking at the second example a tool must return a KoID and thus 
will return a identifying string combined with a translated string.
Hang on; the translated string is something that only the shape itself 
should know; that i18n call should never be typed more then ones, let 
alone appear in another plugin.

Quick explanation for this oddity;
retrieving a ShapeFactory from its registry requires you to get it via the 
KoID, which you can only get if you actually have the ShapeFactory 
already.  The workaround there is to not provide the name part which 
already indicates the problem somewhat.

The current way KoID is used also does a deep copy on each method call 
which means no pointers and thus no way of returning a 'null' or 
'not-valid' value is possible.

For these reasons the usage of an identifyable String and a (translated) 
name should be decoupled for tools and shapes. Where the name is only 
present in the toolfactory and shapefactory and nowhere else. This 
combines nicely with all ways we can show an item to the user; all the 
accessors are in the factory.

Using KoID in Krita has this problem as well;
do a grep for KoID in colorspaces/cmyk_u8 and you will see two different 
translations of the name.
KoID("CMYK", i18n("CMYK")
KoID("CMYK", i18n("CMYK (8-bit integer/channel)")
Same problem in kis_lms_f32_colorspace.* if you think I really had to look 
for it.

I hope I got the problems I have with this across without a need for a 
long thread ;-)
Any feedback is still appreciated, naturally.
-- 
Thomas Zander

[Attachment #5 (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]