kdewebkit tarball gone missing?!

[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:
> > On Thursday, 18 July 2019 00:15:16 CEST René J. V. Bertin wrote:
> > > Albert Astals Cid wrote:
> > > > https://download.kde.org/stable/frameworks/5.60/portingAids/
> > > 
> > > Ah, thanks, I must have missed the announcement of its promotion.
> > > 
> > > So what kind of tier is kdesigner-plugin now - I still have it
> 
> categorised
> 
> > > as a tier3 but those are supposed to depend only on tier1, tier2 and
> 
> tier3
> 
> > > frameworks, no? ;)
> > 
> > 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).

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190720/34b4deec/attachment.sig>