kdewebkit tarball gone missing?!

[Friedrich W. H. Kossebau]

Am Samstag, 20. Juli 2019, 08:19:24 CEST schrieb Volker Krause:
> On Friday, 19 July 2019 16:03:34 CEST Friedrich W. H. Kossebau wrote:
> > Am Freitag, 19. Juli 2019, 09:05:39 CEST schrieb Volker Krause:
> > > Even independent of the dependency rules, webkit support in the 
designer
> > > plugin is a good point to look at.
> > > 
> > > There's three options I see:
> > > (1) remove webkit support from the designer plugin entirely
> > > (2) move webkit support from the designer plugin to a separate plugin
> > > part
> > > of the webkit repo
> > > (3) ignore the problem given it's an optional dependency
> > > 
> > > I'd vote vote for (1) as we obviously don't want to promote usage of 
the
> > > obsolete module, so not offering it in the designer palette anymore
> > > seems
> > > a
> > > step in that direction (and wouldn't break existing code).
> > 
> > IMHO the complete module kdesigner-plugin is a bit broken approach:
> > * being separate from the actual widget code and thus running chance of
> > not
> > getting updated in case widgets get extended/added/deprecated
> > * defeating the idea of independent modules in KDE Frameworks a bit, if
> > you
> > want to have designer support for KItemViews, but pulling in all the 
other
> > widget-providing modules from KDE Frameworks.
> > 
> > IMHO it should be an optional feature to build per widget providing
> > module.
> > And then the plugins should simply become part of the devel packages per
> > module.
> > 
> > I'd be willing to work on (2) to give a sample. And then work on all the
> > other
> 
> Independent of whether we want to keep designer integration for webkit, I
> completely agree with this, same as QML bindings, this should be next to 
the
> module it belongs to.
> 
> Implementation should be straightforward, an example is here https://
> cgit.kde.org/libkdepim.git/tree/src/libkdepim/designer (although the manual
> rpath handling there looks unexpected).

Oh, was not aware KF5DesignerPlugin also provides reuse by other code.

KF5DesignerPlugin comes with a disadvantage though, by adding a build-time 
dependency on it. So would spoil bootstrapping a fresh complete build of KDE 
Frameworks, thus kicking it out of the solution set.

I had been rather thinking to create something purely CMake based, so ECM 
could be used as injection vector, without adding another dep, only bloating 
ECM some more ;) There are other C++-code generating macros already there, so 
would not be a novelty. Personal side goal: make this usable also for the 
Okteta designer plugin, which does some extra needed foo to have some sample 
data to show.

As immediate solution for kdewebkit though, given it is tier 3, using 
KF5DesignerPlugin as another (optional) dep should be fine though, will see 
to prepare a related patches this WE.

Cheers
Friedrich