konq plugins (Re: KParts::TextExtension)

[Dawit A]

On Mon, Sep 27, 2010 at 8:15 PM, David Faure <faure at kde.org> wrote:
> On Monday 27 September 2010, Dawit A wrote:
>> Why ? Would not a simple #if KDE_IS_VERSION(....) suffice in both the
>> header and source files of kwebkitpart_ext ?
>
> Yes for kwebkitpart it's easier. But for the babelfish plugin, my patch
> involves
> - removing the config check for kwebkitpart.h  (and generated header)
> - removing the explicit linking with khtml and kwebkitpart
> - in addition to all the code changes.

Right... I was simply speaking of kwebkitpart. I am definitely aware
of the nightmare of the situation with the konq-plugins.

> The first two points are in cmakelists.txt, so not just done with a #if.
>
>> Anyhow, you need not
>> worry about this since I have already created a stable branch for
>> kwebkitpart already:
>
> Great (tell me when I can commit to kwebkitpart),
> but it doesn't solve the problem with the plugins.

You can go ahead and commit... It has already been branched. I just
need someone to create a kwebkitpart folder under branches/ so that I
can move it there from where it has been branched to now. Apparently
mere mortals do not seem to have karma to create a top level directory
under branches/... :)

> 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...

Regards,
Dawit A.