On Wednesday 26 January 2011, Thorsten Zachmann wrote:
> On Tuesday, January 25, 2011 14:57:07 Cyrille Berger Skott wrote:
> > On Tuesday 25 January 2011, Sven Langkamp wrote:
> > > On Tue, Jan 25, 2011 at 10:49 AM, Dag Andersen wrote:
> > > > Atm I don't have any use for the tools docker nor actu
On Wednesday 26 January 2011, Thorsten Zachmann wrote:
> Would it be enough for a GSOC project to create a plugin manager that a
> user can use? If not maybe we should put it on a list of stuff as Junjor
> Job.
There is a KDE-wide widget [1]. The problem is that (for some reason) we use a
custom
On Tuesday, January 25, 2011 14:57:07 Cyrille Berger Skott wrote:
> On Tuesday 25 January 2011, Sven Langkamp wrote:
> > On Tue, Jan 25, 2011 at 10:49 AM, Dag Andersen wrote:
> > > Atm I don't have any use for the tools docker nor actually any other
> > > docker except the Scripting docker in plan
On Tue, Jan 25, 2011 at 3:25 PM, Sven Langkamp wrote:
> On Tue, Jan 25, 2011 at 11:07 AM, Pierre Stirnweiss <
> pstirnwe...@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 unfi
On Tue, Jan 25, 2011 at 11:07 AM, Pierre Stirnweiss <
pstirnwe...@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 rig
On Tuesday 25 January 2011, Sven Langkamp wrote:
> On Tue, Jan 25, 2011 at 10:49 AM, Dag Andersen 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 ha
On Tue, Jan 25, 2011 at 10:49 AM, Dag Andersen 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 load
On Tue, Jan 25, 2011 at 10:49 AM, Dag Andersen 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 load
My first thought was that this contradicts with the idea of a plugin. Would you
still be able to use third-party plugins that you haven't enabled explicitly in
Plan's source code? Maybe for each plugin it'd be helpful to have a list of
"supporting applications" in the plugins .desktop file.
Am
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
u
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
11 matches
Mail list logo
