[Kde-bindings] A new attempt on PyKDE5 binding generation
Albert Astals Cid
aacid at kde.org
Sun Apr 3 23:14:47 BST 2016
El diumenge, 3 d’abril de 2016, a les 23:04:48 CEST, Ingo Klöcker va escriure:
> On Sunday 03 April 2016 20:27:27 Shaheed Haque wrote:
> > What seems to be causing ripples is my suggestion that I call the
> > *tool* to create the SIP files something relating to PyKDE5. That made
> > sense to me since the tools is all about making SIP wrappers for all
> > of KDE(5) that wants them. Similarly, the current name of the git
> > repo is pykde5.git and I plan to land the KF5 bindings there.
> > However, as I suggested, some non-KF5 projects may find it convenient
> > to host their bindings there too (subject to the what little I
> > understand about the current CMake setup), and so that name too made
> > sense to me.
> What do you think about simply dropping the 5 from the name and instead
> using the 5 as major version number? So, instead of PyKDE5 it would be
> PyKDE v5.x.
What is "pykde"?
My very limited understanding is:
* set of bindings for python for various libraries released by the KDE
* Those libraries are all Qt5 based
* Most of those libraries are part of KF5 but some are not
Since it's not all KF5 we can't call it pykf5.
pyqt5 would be misleading since would seem it's pythong bindings for qt itself
pykdeqt5 is a bit of a mouthful but is not bad either, it's the set of py
bindings for kde software for qt5
pykde has the "brand recognition" benefit i guess since it's similar to what
we've been calling it, in that case though i'd prefer we don't use v5.x since
people would read it as "KDE5" anyway and that's a name we're trying to fight
off, so if pykde is chosen as a name i'd suggest going with a date based
versioning like YY.MM
Now I have a different question, given the modularization we've had, does it
make sense to ship all the pykde bindings in a single repo? Wouldn't it make
more sense for each library to ship it's binding inside? Would that mean an
extra dependency for each library? What dependency would that be?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel