python bindings

Hi, I see that 5.31.0 marked the introduction of python bindings. That's nice (once you figure out how to get them to build) but does that mean there will be no standalone py-kde project like there was for KDE4? IOW, building the bindings and for what python version is something that will

Python bindings using cppyy (was: An update on Python bindings)

As promised, here is an interim update on the investigation into the use of cppyy-based bindings for KF5 (and more...) instead of SIP-based bindings. The first thing is that the underlying technology of cppyy, cling/ROOT, has been under development at CERN for quite a while. It directly reads regu

Re: Python bindings using cppyy (was: An update on Python bindings)

I'm afraid that there has been no progress as I am buried in "startup" mode. I'm not sure when that might change. On Mon, 5 Nov 2018, 14:02 Philipp A. Hi Shaheed! > > The year is nearing its end, and I wonder if there has been any progress > and/or if you people need help with the bindings! > > I

Re: Python bindings using cppyy (was: An update on Python bindings)

Hi Shaheed! The year is nearing its end, and I wonder if there has been any progress and/or if you people need help with the bindings! I’d really like to revive my IPython console in Kate :D Best, Philipp Shaheed Haque schrieb am Sa., 13. Jan. 2018 um 19:06 Uhr: > Thanks to some upstream fixe

Re: Python bindings using cppyy (was: An update on Python bindings)

... wasn't there also some python related work by Stefan? Or is that unrelated? Greetings Dominik Am Mo., 5. Nov. 2018, 16:20 hat Shaheed Haque geschrieben: > I'm afraid that there has been no progress as I am buried in "startup" > mode. I'm not sure when that might change. > > On Mon, 5 Nov 2

Re: Python bindings using cppyy (was: An update on Python bindings)

Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and also Qt5 (see below) showing signs of life. Notes: 1. The packaging has advanced to the point where I think ECM-based framework-by-framework bindings are a real possibility, with both Py2 and Py3. AFAICS, this add

Re: Python bindings using cppyy (was: An update on Python bindings)

El dissabte, 13 de gener de 2018, a les 18:05:45 CET, Shaheed Haque va escriure: > Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and > also Qt5 (see below) showing signs of life. > Notes: This is awesome, i'm really happy we're in a point that framework-by-framework is

Re: Python bindings using cppyy (was: An update on Python bindings)

Hi Luca, On 15 January 2018 at 08:24, Luca Beltrame wrote: > Il giorno Sat, 13 Jan 2018 18:05:45 + > Shaheed Haque ha scritto: > > Hello Shaheed, > > >1. The packaging has advanced to the point where I think ECM-based > >framework-by-framework bindings are a real possibility, with b

Re: Python bindings using cppyy (was: An update on Python bindings)

On Sun, Jan 14, 2018 at 7:05 AM, Shaheed Haque wrote: > Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and > also Qt5 (see below) showing signs of life. Notes: Hi Shaheed, > > The packaging has advanced to the point where I think ECM-based > framework-by-framework binding

Re: Python bindings using cppyy (was: An update on Python bindings)

Hi all, I have a preliminary version of the Cppyy bindings generator CMake support available here: https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-experimental-version-of-a/diff There are some TODOs yet to be addressed, but I would appreciate feedback on how easy it woul

Re: Python bindings using cppyy (was: An update on Python bindings)

A progress update... On 24 October 2017 at 13:05, Shaheed Haque wrote: > Hi all, > > I have a preliminary version of the Cppyy bindings generator CMake > support available here: > > > https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-experimental-version-of-a/diff > > There

Re: Python bindings using cppyy (was: An update on Python bindings)

El dijous, 2 de novembre de 2017, a les 18:22:38 CET, Shaheed Haque va escriure: > A progress update... > > On 24 October 2017 at 13:05, Shaheed Haque wrote: > > Hi all, > > > > I have a preliminary version of the Cppyy bindings generator CMake > > > > support available here: > > https://b

Re: Python bindings using cppyy (was: An update on Python bindings)

Albert, On 2 November 2017 at 21:43, Albert Astals Cid wrote: > El dijous, 2 de novembre de 2017, a les 18:22:38 CET, Shaheed Haque va > escriure: >> A progress update... >> >> On 24 October 2017 at 13:05, Shaheed Haque wrote: >> > Hi all, >> > >> > I have a preliminary version of the Cppyy bind

Re: Python bindings using cppyy (was: An update on Python bindings)

Hi Shaheed, Thank you so much for all your work! a framework-by-framework integration of the binding generation logic (as > previously pioneered by Steve) probably cannot work in general because > there are cases where multiple frameworks contribute to to the same C++ > namespace […] > > The prob

Re: Python bindings using cppyy (was: An update on Python bindings)

Philipp, On 3 November 2017 at 12:52, Philipp A. wrote: > Hi Shaheed, > > Thank you so much for all your work! > >> a framework-by-framework integration of the binding generation logic (as >> previously pioneered by Steve) probably cannot work in general because there >> are cases where multiple

Re: Python bindings using cppyy (was: An update on Python bindings)

Hi Philipp, On 3 November 2017 at 14:09, Philipp A. wrote: > Hi Shaheed, > > Shaheed Haque schrieb am Fr., 3. Nov. 2017 um 14:16 > Uhr: >> >> Philipp, >> >> - my overall understanding of this technique is that it may end up >> being fragile, especially given the difference between P2 and P3. > >

Re: Python bindings using cppyy (was: An update on Python bindings)

Hi Shaheed, Shaheed Haque schrieb am Fr., 3. Nov. 2017 um 14:16 Uhr: > Philipp, > > - my overall understanding of this technique is that it may end up > being fragile, especially given the difference between P2 and P3. > Python 2? I’m sure we shouldn’t include into our decision making an obsole

Re: Python bindings using cppyy (was: An update on Python bindings)

Hi, On Friday 2017-11-03 12:52, Philipp A. wrote: Am I missing something? Namespaces should be Python modules, not classes. If we can do represent them this way, the problem is solveable: https://packaging.python.org/guides/packaging-namespace-packages/ there are two different things that shou

Re: Python bindings using cppyy (was: An update on Python bindings)

Wim, Philipp, On 4 November 2017 at 16:45, Philipp A. wrote: > Hi Wim! > >> So now I have a (C++) namespace 'A' that bears no relationship to anything >> to do with the file system or any type of Python packaging: it exists only >> in memory for the duration of the python session. > > > Yeah, coo

Re: Python bindings using cppyy (was: An update on Python bindings)

Hi Wim! So now I have a (C++) namespace 'A' that bears no relationship to anything > to do with the file system or any type of Python packaging: it exists only > in memory for the duration of the python session. > Yeah, cool, so we just use a path hook and are ready to go right? https://www.pyth

Re: Python bindings using cppyy (was: An update on Python bindings)

Hi Shaheed, Thank you for the clarifications! My observation is that *nobody* is likely to help with that problem: the > framework owners did > nothing obvious to either keep PyKDE4 going (out of tree) or to help > Steve with my earlier SIP based efforts (in tree). > It's a bit sad, but not too

Re: Python bindings using cppyy (was: An update on Python bindings)

There is a POC-quality implementation of the integration with KDE here: https://cgit.kde.org/pykde5.git/tree/?h=srhaque-cppyy-bindings&id=19a94fb3ae2b40a985913ed4e49400e02df56dc2 This contains examples of bindings for Akonadi and KDcraw. My next steps will be to do a few more, and then move on to

Re: Python bindings using cppyy (was: An update on Python bindings)

On Sat, 4 Nov 2017, Chris Burel wrote: > I think this is a remarkably short sighted statement. It assumes that people > that would use these bindings have no existing Python codebase at all, and > can afford to start a brand new project. The reality is much different. > > Let's take a specific

Re: Python bindings using cppyy (was: An update on Python bindings)

> On Nov 4, 2017, at 4:46 AM, Philipp A. wrote: > > Entirely new bindings lead to new applications being written using those > bindings. Writing applications in Python 2 is an immediate maintenance burden > and people only do it because of stubborn ideology or a complete lack of > awareness

Re: Python bindings using cppyy (was: An update on Python bindings)

Hi Shaheed, Chris, Shaheed Haque schrieb am Sa., 4. Nov. 2017 um 18:35 Uhr: > FWIW, I already tried that (types.ModuleType is itself a perfectly > subclassable class!) […] > > Now, none of that may be a limiting factor in the plan you seem to be > discussing, but it was part of what made me thin

Re: Python bindings using cppyy (was: An update on Python bindings)

Philipp, On 5 November 2017 at 14:48, Philipp A. wrote: > Hi Shaheed, Chris, > > Shaheed Haque schrieb am Sa., 4. Nov. 2017 um > 18:35 Uhr: > >> FWIW, I already tried that (types.ModuleType is itself a perfectly >> subclassable class!) […] >> >> Now, none of that may be a limiting factor in the

Re: Python bindings using cppyy (was: An update on Python bindings)

I have made an attempt to get roughly all the bindings I was previously attempting with SIP to be (a) generated and (b) built. As of now, we have: - Customisations with a diffstat that reads "21 files changed, 20 insertions(+), 48 deletions(-)". - All but 5-6 of the formal tier 1, 2 and 3 framewo

Problems with Python bindings in KF5

(CC'ed to the author of the bindings) Hello, There are a few problems with the KF5 Python bindings, which emerged when people (including but not limited to myself) wanted to package them. First of all, they are untestable in anything that's not a Debian based distro, because they

D5981: Fix compilation of Python bindings

aacid created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY We only need to pass TRANSLATION_DOMAIN when compiling the C++ code since it's the only part that contains i18n() calls. Reason: The kloc

D5981: Fix compilation of Python bindings

lbeltrame added a reviewer: lbeltrame. REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D5981 To: aacid, lbeltrame Cc: lbeltrame, #frameworks

D5981: Fix compilation of Python bindings

lbeltrame added a comment. I'll try to test and report back. REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D5981 To: aacid Cc: lbeltrame, #frameworks

D5981: Fix compilation of Python bindings

lbeltrame accepted this revision. This revision is now accepted and ready to land. REPOSITORY R249 KI18n BRANCH master REVISION DETAIL https://phabricator.kde.org/D5981 To: aacid, lbeltrame Cc: lbeltrame, #frameworks

D5981: Fix compilation of Python bindings

This revision was automatically updated to reflect the committed changes. Closed by commit R249:adca5fa181a0: Fix compilation of Python bindings (authored by aacid). REPOSITORY R249 KI18n CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D5981?vs=14868&id=14877 REVISION DETAIL h

Dropping dead(?) Python bindings generation code?

Hi, trying to ensure some changes do not break the Python binding generation, I actually tried to activate that, but found at least on current openSUSE TW there seem to be no longer any working dependencies. Also the openSUSE TW packages of the KF modules seem to also be build without bindings,

D26430: Fix Python bindings compilation after 7ab8275bdb56882692846d046a5bbeca5795b009

arojas created this revision. arojas added reviewers: davidedmundson, broulik, dfaure. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. arojas requested review of this revision. REVISION SUMMARY Exclude the new function from the sip parser TEST PLAN Python

D26430: Fix Python bindings compilation after 7ab8275bdb56882692846d046a5bbeca5795b009

dfaure accepted this revision. This revision is now accepted and ready to land. REPOSITORY R237 KConfig REVISION DETAIL https://phabricator.kde.org/D26430 To: arojas, davidedmundson, broulik, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D26430: Fix Python bindings compilation after 7ab8275bdb56882692846d046a5bbeca5795b009

This revision was automatically updated to reflect the committed changes. Closed by commit R237:171a2c26d280: Fix Python bindings compilation after 7ab8275bdb56882692846d046a5bbeca5795b009 (authored by arojas). REPOSITORY R237 KConfig CHANGES SINCE LAST UPDATE https://phabricator.kde.org

D26815: Fix python bindings build after ebd14f29f8052ff5119bf97b42e61f404f223615

arojas created this revision. arojas added reviewers: nicolasfella, dfaure. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. arojas requested review of this revision. REVISION SUMMARY The new API breaks python bindings compilation since sip can't under

D26815: Fix python bindings build after ebd14f29f8052ff5119bf97b42e61f404f223615

nicolasfella accepted this revision. nicolasfella added a comment. This revision is now accepted and ready to land. looks sensible, but I haven't tried it myself REPOSITORY R237 KConfig REVISION DETAIL https://phabricator.kde.org/D26815 To: arojas, nicolasfella, dfaure Cc: kde-frameworks

D26815: Fix python bindings build after ebd14f29f8052ff5119bf97b42e61f404f223615

This revision was automatically updated to reflect the committed changes. Closed by commit R237:68c1cfd0d8dc: Fix python bindings build after ebd14f29f8052ff5119bf97b42e61f404f223615 (authored by arojas). REPOSITORY R237 KConfig CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D26815

D11055: Pack python bindings into right dirs

McPain abandoned this revision. Herald edited subscribers, added: kde-buildsystem, kde-frameworks-devel; removed: Frameworks, Build System. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D11055 To: McPain, vkrause Cc: kde-frameworks-devel, kde-buildsystem, a

D15559: Python bindings: use cmake_parse_arguements, fix documentation

bruns created this revision. bruns added a reviewer: Frameworks. Herald added projects: Frameworks, Build System. Herald added subscribers: kde-buildsystem, kde-frameworks-devel. bruns requested review of this revision. REVISION SUMMARY Use of positional arguments is error prone, as e.g. switchi

D15559: Python bindings: use cmake_parse_arguments, fix documentation

bruns retitled this revision from "Python bindings: use cmake_parse_arguements, fix documentation" to "Python bindings: use cmake_parse_arguments, fix documentation". bruns edited the summary of this revision. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https:/

D15559: Python bindings: use cmake_parse_arguments, fix documentation

bruns added a reviewer: dfaure. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D15559 To: bruns, #frameworks, dfaure Cc: kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D15559: Python bindings: use cmake_parse_arguments, fix documentation

bruns updated this revision to Diff 41952. bruns added a comment. Fix parentheses REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D15559?vs=41772&id=41952 BRANCH python_ecm_cleanup REVISION DETAIL https://phabricator.kde.org/D15559 AFFECTED

D15559: Python bindings: use cmake_parse_arguments, fix documentation

dfaure accepted this revision. dfaure added a comment. This revision is now accepted and ready to land. This is technically not 100% source compatible, but since the callers were already passing "TARGET" (and others) as documented, I guess it's fine. REPOSITORY R240 Extra CMake Modules BRA

D15559: Python bindings: use cmake_parse_arguments, fix documentation

This revision was automatically updated to reflect the committed changes. Closed by commit R240:b322901ca22f: Python bindings: use cmake_parse_arguments, fix documentation (authored by bruns). REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D15559

D11055: Pack python bindings into right dirs

McPain created this revision. McPain added a reviewer: vkrause. Restricted Application added projects: Frameworks, Build System. Restricted Application added subscribers: Build System, Frameworks. McPain requested review of this revision. REVISION SUMMARY 1. Python modules are packed into /usr/l

D11055: Pack python bindings into right dirs

apol added inline comments. INLINE COMMENTS > FindPythonModuleGeneration.cmake:448 > if (GPB_SIP_DEPENDS MATCHES PyKF5) > - set(_kf5_python_prefix > ${CMAKE_INSTALL_PREFIX}/lib/python${pyversion${pyversion}_maj_min}/${GPB_INSTALL_DIR_SUFFIX}) > + set(_kf5_python_prefix

D11055: Pack python bindings into right dirs

arojas added a comment. The sip part is distro-specific. At least in Arch we don't have separate sip/sip3 directories (what's the point? sip files are independent of the python version) REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D11055 To: McPain, v

Re: Problems with Python bindings in KF5

In data sabato 15 aprile 2017 16:10:24 CEST, Luca Beltrame ha scritto: > https://build.opensuse.org/build/ > home:luca_b:branches:KDE:Unstable:Frameworks/openSUSE_Factory/x86_64/ki18n/ > _log As these build logs are only available to users logged in the OBS, the error is pasted here as well (no ex

Re: Problems with Python bindings in KF5

El dissabte, 15 d’abril de 2017, a les 16:10:24 CEST, Luca Beltrame va escriure: > (CC'ed to the author of the bindings) > > Hello, > > There are a few problems with the KF5 Python bindings, which emerged when > people (including but not limited to myself) wanted to pack

Re: Problems with Python bindings in KF5

In data sabato 15 aprile 2017 23:42:54 CEST, Albert Astals Cid ha scritto: > This last sentence is more confontrational that it needs to be, software > will have bugs, let's work to fix them instead of throwing accusations and > blame around :) To give more context: this comes after a few days of

Re: Problems with Python bindings in KF5

> As these build logs are only available to users logged in the OBS, the > error is pasted here as well (no expiration): > > http://paste.opensuse.org/16013900 Stephen, can you take a look? I'm afraid we'll have to disable the python bindings if nobody fixes them. --

Re: Problems with Python bindings in KF5

enSUSE_Factory/x86_64/ki18n >>> / >>> _log >> As these build logs are only available to users logged in the OBS, the >> error is pasted here as well (no expiration): >> >> http://paste.opensuse.org/16013900 > Stephen, can you take a look? > > I'm

Re: Problems with Python bindings in KF5

In data venerdì 5 maggio 2017 19:42:45 CEST, Stephen Kelly ha scritto: > Is KI18n the only one with the problem? At the moment, yes. All the other failures I saw were just a case of missing sip files. > I can't reproduce it on my Ubuntu. Can someone dig in on opensuse to > reduce the code to fi

Re: Problems with Python bindings in KF5

In data venerdì 5 maggio 2017 22:47:45 CEST, Luca Beltrame ha scritto: > From a quick discussion on #opensuse-kde, it may have to do with > QT_NO_CAST_FROM_ASCII and QT_NO_CAST_TO_ASCII (which means that we have My initial test suggests that indeed we have a problem somehow with strings- to-QStri

Re: Problems with Python bindings in KF5

In data sabato 6 maggio 2017 00:01:09 CEST, Luca Beltrame ha scritto: > I'll try rebuilding a few more times (the result is unreliable) and I'll > report back. False alarm: it wasn't the problem at all. I can't see what could be wrong from the generated files. -- Luca Beltrame - KDE Forums tea

Re: Problems with Python bindings in KF5

On 04/15/2017 10:53 PM, Luca Beltrame wrote: > I can't understand the error thrown by ki18n (when it does not build) or I'd > have attempted to fix it myself... Hi, sorry for my delayed response. Should we disable the ki18n bindings at this point? I'm fine with doing that until someone can repro

Re: Problems with Python bindings in KF5

El dijous, 25 de maig de 2017, a les 1:02:58 CEST, Stephen Kelly va escriure: > On 04/15/2017 10:53 PM, Luca Beltrame wrote: > > I can't understand the error thrown by ki18n (when it does not build) or > > I'd have attempted to fix it myself... > > Hi, sorry for my delayed response. > > Should we

Re: Problems with Python bindings in KF5

On 05/26/2017 10:21 PM, Albert Astals Cid wrote: > El dijous, 25 de maig de 2017, a les 1:02:58 CEST, Stephen Kelly va escriure: >> On 04/15/2017 10:53 PM, Luca Beltrame wrote: >>> I can't understand the error thrown by ki18n (when it does not build) or >>> I'd have attempted to fix it myself... >>

D7677: Fix python bindings compilation after 7af93dd23873d0b9cdbac192949e7e5114940aa6

arojas created this revision. Restricted Application added projects: Frameworks, Build System. Restricted Application added subscribers: Build System, Frameworks. REVISION SUMMARY Explicitely set LIBRARY_OUTPUT_DIRECTORY for the python module TEST PLAN kcoreaddons python bindings are

D7677: Fix python bindings compilation after 7af93dd23873d0b9cdbac192949e7e5114940aa6

dfaure accepted this revision. dfaure added a comment. This revision is now accepted and ready to land. Thanks for the fix! REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D7677 To: arojas, dfaure, skelly Cc: #frameworks, #build_system

D7677: Fix python bindings compilation after 7af93dd23873d0b9cdbac192949e7e5114940aa6

This revision was automatically updated to reflect the committed changes. Closed by commit R240:8b4033f16c2a: Fix python bindings compilation after 7af93dd23873d0b9cdbac192949e7e5114940aa6 (authored by arojas). REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE https

Re: Dropping dead(?) Python bindings generation code?

es we did, but the build of these on KDE CI has been disabled for a long time because the Python bindings did not build reliably. This was caused by dependency sequencing issues from my understanding within CMake. Consequently we would get builds falling over periodically for no reason other than

D26431: Fix build of python bindings for kcolumnheadersmodel

. TEST PLAN Python bindings build for kitemmodels REPOSITORY R275 KItemModels REVISION DETAIL https://phabricator.kde.org/D26431 AFFECTED FILES src/core/kcolumnheadersmodel.h To: arojas, dfaure, ahiemstra, davidedmundson Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D26431: Fix build of python bindings for kcolumnheadersmodel

ahiemstra accepted this revision. ahiemstra added a comment. This revision is now accepted and ready to land. Silly sip :/ REPOSITORY R275 KItemModels REVISION DETAIL https://phabricator.kde.org/D26431 To: arojas, dfaure, ahiemstra, davidedmundson Cc: kde-frameworks-devel, LeGast00n, GB_

D26431: Fix build of python bindings for kcolumnheadersmodel

This revision was automatically updated to reflect the committed changes. Closed by commit R275:89e24bd88ea7: Fix build of python bindings for kcolumnheadersmodel (authored by arojas). REPOSITORY R275 KItemModels CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D26431?vs=72789&id=7

D22314: Don't try to generate python bindings for kmodifierkeyinfoprovider_p.h

in PyQt5, so sip can't generate bindings for it. TEST PLAN kguiaddons python bindings build correctly for the remaining classes REPOSITORY R273 KGuiAddons REVISION DETAIL https://phabricator.kde.org/D22314 AFFECTED FILES src/CMakeLists.txt To: arojas, dfaure Cc: kde-frameworks-

D22314: Don't try to generate python bindings for kmodifierkeyinfoprovider_p.h

dfaure added a reviewer: apol. REPOSITORY R273 KGuiAddons REVISION DETAIL https://phabricator.kde.org/D22314 To: arojas, dfaure, apol Cc: kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

D22314: Don't try to generate python bindings for kmodifierkeyinfoprovider_p.h

dfaure accepted this revision. dfaure added a comment. This revision is now accepted and ready to land. Makes sense to me - this is private API anyway - but that makes me wonder why Aleix added it explicitly in commit 0fe2990dbad992a4

D22314: Don't try to generate python bindings for kmodifierkeyinfoprovider_p.h

apol accepted this revision. apol added a comment. In D22314#492011 , @dfaure wrote: > Makes sense to me - this is private API anyway - but that makes me wonder why Aleix added it explicitly in commit 0fe2990dbad992a4

D22314: Don't try to generate python bindings for kmodifierkeyinfoprovider_p.h

This revision was automatically updated to reflect the committed changes. Closed by commit R273:071048e32a89: Don't try to generate python bindings for kmodifierkeyinfoprovider_p.h (authored by arojas). REPOSITORY R273 KGuiAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D

Review Request 115725: Switch from yapgvb to Graphviz Python bindings

Description --- Yapgvb turned out to be painful to deploy, and Ben pointed out that Graphviz provides official Python bindings. Those are less Pythonic, but more widespread and it is safe to assume they are maintained. Switching to those bindings also allow us to avoid temporary files, which

[Differential] [Updated] D4510: Python bindings: Restore handling of deprecated constructs.

lbeltrame added reviewers: skelly, Build System, Frameworks. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D4510 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: shaheed, skelly, #build_system, #frameworks Cc: #frameworks

D7736: Not-to-be-merged review fo Python bindings generator

shaheed created this revision. Restricted Application added projects: Frameworks, Build System. Restricted Application added subscribers: Build System, Frameworks. REVISION SUMMARY As per https://marc.info/?l=kde-core-devel&m=150464598710128&w=2, this is a snapshot of the current state of the S

D7736: Not-to-be-merged review fo Python bindings generator

shaheed edited the summary of this revision. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D7736 To: shaheed, lbeltrame Cc: #frameworks, #build_system

D7736: Not-to-be-merged review of Python bindings generator

shaheed retitled this revision from "Not-to-be-merged review fo Python bindings generator" to "Not-to-be-merged review of Python bindings generator". REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D7736 To: shaheed, lbeltrame Cc: #frameworks, #build_system

D7736: Not-to-be-merged review of Python bindings generator

shaheed edited the summary of this revision. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D7736 To: shaheed, lbeltrame Cc: #frameworks, #build_system

D7736: Not-to-be-merged review of Python bindings generator

lbeltrame added a comment. A small number of reviews (this thing is huge). One question: would it be possible to have the bindings per-framework, rather than a single, long list? This is also what made PyKDE4 unwieldy. IOW, each Framework should ship their (optional) bindings. We can put

D7736: Not-to-be-merged review of Python bindings generator

shaheed added a comment. My comments here are phrased as if this SIP-based approach was the solution eventually adopted (cppyy might be different). With that said... This... > (this thing is huge). and this... > One question: would it be possible to have the bindings per-fr

D7736: Not-to-be-merged review of Python bindings generator

shaheed added inline comments. INLINE COMMENTS > lbeltrame wrote in CMakeLists.txt:49 > Don't use `find_package(FOO REQUIRED)`. Use `find_package(FOO)` then > `set_package_properties(FOO TYPE REQUIRED...`. There are many examples in KDE > git you can use. You will need to include FeatureSummary

D7736: Not-to-be-merged review of Python bindings generator

shaheed added a comment. My suggestion would be to focus any review efforts in this order: 1. files in the top level directory. 2. possibly files the ./templates subdirectory. 3. __init__.py and CMakelists.txt in the ./PyKF5 subdirectory. Ignore all other files therein. REPOSITORY

D7736: Not-to-be-merged review of Python bindings generator

jasontibbitts added a comment. I hate to add a ping without any useful review, but I'm quite interested in this effort as I have a pykde4-based application which I would really like to get ported to the modern frameworks. Current distro packages of pykde4 are increasingly broken, and covera

D7736: Not-to-be-merged review of Python bindings generator

shaheed added a comment. In https://phabricator.kde.org/D7736#154948, @jasontibbitts wrote: > I hate to add a ping without any useful review, but I'm quite interested in this effort as I have a pykde4-based application which I would really like to get ported to the modern frameworks. Cu

D7736: Not-to-be-merged review of Python bindings generator

jasontibbitts added a comment. Thanks for the update; I'll follow the bindings list and work on getting cppyy into Fedora. Hopefully that will be relatively uncomplicated. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D7736 To: shaheed, lbeltrame Cc: j

Re: Review Request 115725: Switch from yapgvb to Graphviz Python bindings

without graphviz python bindings installed). - Alex Merry On Feb. 13, 2014, 2:22 p.m., Aurélien Gâteau wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.

Re: Review Request 115725: Switch from yapgvb to Graphviz Python bindings

o be painful to deploy, and Ben pointed out that Graphviz > provides official Python bindings. Those are less Pythonic, but more > widespread and it is safe to assume they are maintained. Switching to those > bindings also allow us to avoid temporary files, which is a nice bonus. > &

Re: Review Request 115725: Switch from yapgvb to Graphviz Python bindings

marked as submitted. Review request for KDE Frameworks and Alex Merry. Repository: kapidox Description --- Yapgvb turned out to be painful to deploy, and Ben pointed out that Graphviz provides official Python bindings. Those are less Pythonic, but more widespread and it is safe to assume

Re: Adding Python bindings for some frameworks in the next release

On dimanche 19 juin 2016 21:29:37 CEST Stephen Kelly wrote: > Hi, > > I would like to add the python bindings previously discussed to the next > release of KF5. This means adding the four most recent commits from > > https://github.com/steveire/extra-cmake-modules/commi

D15091: Compile python bindings with the same sipname used by PyQt

arojas created this revision. arojas added reviewers: Frameworks, bruns. Herald added projects: Frameworks, Build System. Herald added subscribers: kde-buildsystem, kde-frameworks-devel. arojas requested review of this revision. REVISION SUMMARY PyQt>=5.11 is compiled with the 'PyQt5.sip' sipnam

D15091: Compile python bindings with the same sipname used by PyQt

bruns added inline comments. INLINE COMMENTS > run-sip.py:11 > +from PyQt5.Qt import PYQT_CONFIGURATION > +pyqt_sip_flags = PYQT_CONFIGURATION["sip_flags"].split(' ') > +index_n = pyqt_sip_flags.index('-n') Is there a gurantee `-n` and its arg are space separated? otherwise: impo

D15091: Compile python bindings with the same sipname used by PyQt

arojas updated this revision to Diff 40479. arojas added a comment. Use a regex to account for the case where -n an its arg are not space-separated REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D15091?vs=40477&id=40479 REVISION DETAIL https:

D15091: Compile python bindings with the same sipname used by PyQt

arojas added inline comments. INLINE COMMENTS > bruns wrote in run-sip.py:11 > Is there a gurantee `-n` and its arg are space separated? > > otherwise: > > import re > m = re.search('-n\s*(\S+)', PYQT_CONFIGURATION["sip_flags"]) > if m: > sipArgs = ['-n', m.group(1)] + sipArgs I find

D15091: Compile python bindings with the same sipname used by PyQt

arojas marked an inline comment as done. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D15091 To: arojas, #frameworks, bruns Cc: kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D15091: Compile python bindings with the same sipname used by PyQt

rdieter added a comment. Why are you simply not using all PYQT_CONFIGURATION["sip_flags"]? REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D15091 To: arojas, #frameworks, bruns Cc: rdieter, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D15091: Compile python bindings with the same sipname used by PyQt

arojas added a comment. In D15091#316150 , @rdieter wrote: > Why are you simply not using all PYQT_CONFIGURATION["sip_flags"]? Not sure if we really want to do this. For instance, bindings would get tagged with the Qt version that PyQt w

D15091: Compile python bindings with the same sipname used by PyQt

rdieter added a comment. I was asking mostly because that's what pyqt upstream strongly suggested (to use all sip_flags) when I asked them. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D15091 To: arojas, #frameworks, bruns Cc: rdieter, kde-frameworks-d

D15091: Compile python bindings with the same sipname used by PyQt

arojas added a comment. In D15091#316243 , @rdieter wrote: > I was asking mostly because that's what pyqt upstream strongly suggested (to use all sip_flags) when I asked them. Oh, if upstream recommends it then I guess it should cause no

D15091: Compile python bindings with the same sipname used by PyQt

rdieter added a comment. These 2 threads: https://www.riverbankcomputing.com/pipermail/pyqt/2018-August/040759.html https://www.riverbankcomputing.com/pipermail/pyqt/2018-August/040771.html REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D15091 To: aro

  1   2   >