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

List:       kde-core-devel
Subject:    Re: konq plugins, new kde module? (Re: KParts::TextExtension)
From:       David Faure <faure () kde ! org>
Date:       2010-09-28 11:08:10
Message-ID: 201009281308.10780.faure () kde ! org
[Download RAW message or body]

On Tuesday 28 September 2010, Dawit A wrote:
> You can go ahead and commit... 

Done.

> I just need someone to create a kwebkitpart folder under branches/

Done.

> > In fact, I don't understand why they are in extragear. I mean, yes, the
> > initial idea for kdeaddons was "so that they can be optionally
> > installed", but nowadays it means "and they have a separate release
> > cycle" which makes no sense whatsoever, given that they are tied to
> > konqueror anyway.
> 
> Agreed. Makes no sense to me neither...
> 
> > Every time someone changes something in kdelibs or konqueror which
> > affects the plugins, this same problem arises. Not that we make bin
> > incompat changes, but just depending on new features (from kdelibs or
> > konq) is a huge issue every time.
> 
> Yep, that is a very big problem right now...
> 
> > ==> How about we move these plugins to kdebase?
> > Not all of them - not entirely separate views like fsview, but at least
> > the HTML-related plugins, like rellinks, adblock, uachanger, babelfish,
> > validators, domtreeviewer, khtmlsettingsplugin, searchbar?
> > They are certainly not essential -- nothing ever is -- but they go
> > together with konqueror, really. I actually miss kdeaddons for this; it
> > had the advantage of being "not in the core set of packages" while still
> > being tied to KDE SC releases, so it didn't have the extragear issue of
> > "I have no idea which version of kdelibs I'm being compiled against".
> > Why did we drop kdeaddons, again?
> 
> How about simply creating a new KDE repo, "kdeplugins",  which should
> only be used for containing optional plugins for applications that are
> already part of one of the standard KDE packages ? That way the module
> would not be used as a dumping ground for everything that does not fit
> one of the other standard packages...
> 
> Regardless though the plugins need to go somewhere where they can be
> properly branched and tagged to avoid the current maintenance
> nightmare...

I agree, kdeplugins sounds like a good idea.

Released as part of KDE SC, but with a build-time dependency on the other 
modules, so that it can use libkonq, akregator code, etc.

Any opinions, anyone else?

-- 
David Faure, faure@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
[prev in list] [next in list] [prev in thread] [next in thread]