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

List:       kde-bindings
Subject:    Re: [Kde-bindings] Progress report on Py*5 binding generation
From:       Stephen Kelly <steveire () gmail ! com>
Date:       2016-04-23 17:04:43
Message-ID: 571bab2b.55301c0a.346bc.4bb3 () mx ! google ! com
[Download RAW message or body]

Shaheed Haque wrote:

> As I said, this is a common pattern without an obvious workaround

It's quite worrying that this is common. I will look into this, because 
instinctively I think something can be fixed in the kio headers here.

> Frankly, I doubt this does make sense except where the owner of the code
> cares enough to generate stuff by hand, and I consider this to be a
> non-starter from my point of view.

I don't know what needs to be generated by hand?

> Specifically for KF5, if all the
> framework owners cared enough about the Python bindings, they could have
> written their own, and we would not be having this discussion!

I'm not certain that's true :).

> Now, the game might change once we have PyQt5 + PyKF5: e.g. binding
> something finite like Krita or whatever might be done by hand, but nobody
> will bother till the core libraries are there. Except that if the tools
> are good enough to handle KF5, there should be few reasons to bother doing
> it by hand.

Yes, I think we have the same goal there.

> Notice that the hardcoded includes are only needed for the person
> generating/compiling/packaging the bindings in #1. The .SIP files in #2
> can contain the %Extract section, and it will just be ignored by anybody
> %Import'ing it.

Ah, I didn't realize that. If I understand now, then that's what I was 
missing.

> Now, CMake does have a role in #1 in that it could be used to set the
> --includes as you did for the SIP generation. The %Extract includes is
> simply a way to pass this knowledge through SIP to the C++ compilation
> step.
> 
> Does that sound right?

I think I understand now, but I don't think that's necessary.

I've pushed two commits to 

 https://github.com/steveire/extra-cmake-modules/commits/generate-python-bindings

which contains a fork of your sip_generator and rules_engine. I didn't need 
anything else to implement my proof of concept.

It also contains a cmake macro to generate bindings and install them and 
install the sip files. To proove the concept I ported kitemmodels and 
kcoreaddons to use the macro:

 https://github.com/steveire/kcoreaddons/commit/979c75f3

 https://github.com/steveire/kitemmodels/commit/d7511fea

I can now use the attached python file to use KItemModels.

Please let me know what you think of this approach.

Note that 

* IMO It makes sense to version the bindings (and rules) with the source
* IMO It makes sense to CI test the bindings with the source
* The linking is simple because we are building a real library with cmake, 
and so target_link_libraries works (transitively)
* Ditto, we get transitive computation of the include directories to pass to 
the generator from CMake.
* It works with python 2 and 3.
* Nothing is generated 'by hand'
* This is all WIP. I just did it this afternoon.


Thanks,

Steve. 

["pythontest.py" (text/x-python)]

#!/usr/bin/env python3
#-*- coding: utf-8 -*-

import sys

from PyQt5 import QtCore
from PyQt5 import QtWidgets

from PyKF5 import KItemModels

def main():
    app = QtWidgets.QApplication(sys.argv)

    stringListModel = QtCore.QStringListModel(["Monday", "Tuesday", "Wednesday",
        "Thursday", "Friday", "Saturday", "Sunday"]);

    treeView = QtWidgets.QTreeView()
    treeView.setModel(stringListModel)
    treeView.setSelectionMode(QtWidgets.QTreeView.ExtendedSelection)
    treeView.resize(400, 400)
    treeView.show()

    selectionProxy = KItemModels.KSelectionProxyModel()
    selectionProxy.setSelectionModel(treeView.selectionModel())
    selectionProxy.setSourceModel(stringListModel)

    selectedTreeView = QtWidgets.QTreeView()
    selectedTreeView.setModel(selectionProxy)
    selectedTreeView.resize(400, 400)
    selectedTreeView.show()

    app.exec_()

if __name__ == '__main__':
    main()


[Attachment #4 (text/plain)]

_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings


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