[prev in list] [next in list] [prev in thread] [next in thread]
List: calligra-devel
Subject: Re: tools docker etc in plan
From: Sven Langkamp <sven.langkamp () gmail ! com>
Date: 2011-01-25 14:25:48
Message-ID: AANLkTi==H-0Yr+PLTZfA3s_eCszsAi3sTTffxahWS2Og () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Jan 25, 2011 at 11:07 AM, Pierre Stirnweiss <
pstirnweiss@googlemail.com> wrote:
> To be honest, I think we should think a bit further. My impression (when I
> was looking into tools/plugins loading mechanism for the (still unfinished)
> change tracking tool) is that the system is very rigid and basically depends
> on the developer knowing what plugins are there what plugins would be
> usefull. There also is the case where some tools of one particular plugin
> does not make sense (expl, the change tracking tool of the textshape plugin
> doesn't make sense outside words, because odf does not foresee change
> tracking outside a text document).
> I think we should revisit how our plugins/tools are loaded and allow more
> flexibility at runtime to set which are the plugins to be loaded (also by
> users). After all, the whole point of the plugin system is to allow external
> plugins to be designed. So there should be a way to set this up, other than
> calligra core developpers explicitely allowing/disallowing plugins/tools.
>
Only plugins that flake loads by default should need to be blacklisted.
Usually external developers shouldn't add plugins with that type. The change
tracking tool could be loaded as Words plugin, just as the Krita tools that
have the Krita/Tool plugin type.
> On a side note, it seems that at application startup, all the plugins are
> loaded serialised and only when this is finished will the application load
> further. That's ok when we have only a handfull of plugin installed but the
> system does not scale very much. Can't we have non critical plugins load in
> parrallel to further application startup?, in a different thread?
>
> PierreSt
>
>
> On Tue, Jan 25, 2011 at 10:49 AM, Dag Andersen <danders@get2net.dk> wrote:
>
>> Atm I don't have any use for the tools docker nor actually any other
>> docker
>> except the Scripting docker in plan.
>> This *may* change in the future of course, so it would be nice to have a
>> way
>> of controlling which plugins should be loaded. AFAICS it's possible to
>> *disable* plugins if you know their id. I'd rather have the possibility to
>> *enable* those I use and have everything else disabled.
>> Anybody knows how this could most easily be achived?
>> --
>> Mvh.
>> Dag Andersen
>> _______________________________________________
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>
>
> _______________________________________________
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
[Attachment #5 (text/html)]
<div class="gmail_quote">On Tue, Jan 25, 2011 at 11:07 AM, Pierre Stirnweiss <span \
dir="ltr"><<a href="mailto:pstirnweiss@googlemail.com">pstirnweiss@googlemail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; \
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> To be honest, I think \
we should think a bit further. My impression (when I was looking into tools/plugins \
loading mechanism for the (still unfinished) change tracking tool) is that the system \
is very rigid and basically depends on the developer knowing what plugins are there \
what plugins would be usefull. There also is the case where some tools of one \
particular plugin does not make sense (expl, the change tracking tool of the \
textshape plugin doesn't make sense outside words, because odf does not foresee \
change tracking outside a text document).<br>
I think we should revisit how our plugins/tools are loaded and allow more flexibility \
at runtime to set which are the plugins to be loaded (also by users). After all, the \
whole point of the plugin system is to allow external plugins to be designed. So \
there should be a way to set this up, other than calligra core developpers \
explicitely allowing/disallowing plugins/tools.<br> </blockquote><div><br>Only \
plugins that flake loads by default should need to be blacklisted. Usually external \
developers shouldn't add plugins with that type. The change tracking tool could \
be loaded as Words plugin, just as the Krita tools that have the Krita/Tool plugin \
type.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; \
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On a side note, it \
seems that at application startup, all the plugins are loaded serialised and only \
when this is finished will the application load further. That's ok when we have \
only a handfull of plugin installed but the system does not scale very much. \
Can't we have non critical plugins load in parrallel to further application \
startup?, in a different thread?<br>
<br>PierreSt<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Tue, \
Jan 25, 2011 at 10:49 AM, Dag Andersen <span dir="ltr"><<a \
href="mailto:danders@get2net.dk" target="_blank">danders@get2net.dk</a>></span> \
wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Atm I don't have any \
use for the tools docker nor actually any other docker<br> except the Scripting \
docker in plan.<br> This *may* change in the future of course, so it would be nice to \
have a way<br> of controlling which plugins should be loaded. AFAICS it's \
possible to<br>
*disable* plugins if you know their id. I'd rather have the possibility to<br>
*enable* those I use and have everything else disabled.<br>
Anybody knows how this could most easily be achived?<br>
<font color="#888888">--<br>
Mvh.<br>
Dag Andersen<br>
_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org" \
target="_blank">calligra-devel@kde.org</a><br> <a \
href="https://mail.kde.org/mailman/listinfo/calligra-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br> \
</font></blockquote></div><br> \
</div></div><br>_______________________________________________<br> calligra-devel \
mailing list<br> <a href="mailto:calligra-devel@kde.org">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br> \
<br></blockquote></div><br>
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic