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

List:       koffice-devel
Subject:    Re: Registries
From:       Thomas Zander <zander () kde ! org>
Date:       2006-06-09 15:17:12
Message-ID: 200606091717.12697.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 9 June 2006 16:49, Boudewijn Rempt wrote:
> But I guess the way I should have done this is:
>
> * query for the desktop file with ktrader
> * store the KService::ptr service for when we need something from that
> plugin * ask the desktop file for all the properties I mentioned above,
> store them too, and use them in the GUI

This implies we are going to store all the strings for tooltip / 
description / name / id / imagename in the desktop file.
Including their translations.

This means we now have the ID in the factory (still need that), in the 
desktop file and in code of other tools/shapes that use.
Ugh; I don't like that prospect.

> * load the library and create the tool, colorspace or whatever only
> when the user uses it. for instance, on the first click on the icon for
> the tool in the toolbar.

I changed the ToolRegistry to not load a kpart plugin anymore, which is 
unneeded.
And with the gcc symbol hiding I personally want to see the resulting 
speed before we optimize where it might not be needed.
Since I am coding a the toolManager and I am not at all sure I like the 
amount of increased complexity loading on demand gives.

 I was finishing up tools and toolbox APIs and rough implementations and 
about to start shapes this weekend to follow the ideas I gathered while 
working on tools.  What was your planning? Should I keep away from them 
for now?
-- 
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]