Program for technical drawing/ circuit diagrams with LaTeX circuit_macros and pstricks.
Ported version 0.4.3 for KDE4 to version 0.5.0 for KF5/Qt5
Minimal changes, but some bugs have been fixed and non-working features removed.
Reporting of errors occurring in LaTeX has been improved.
Details
Details
- Reviewers
ltoscano
Check build/install process works with cmake (instructions in README).
Open .m4 file in examples subdirectory and check that image appears on screen.
Export image as pdf.
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Comment Actions
This is a big much change; do you have a smaller set of changes? We already have a frameworks branch, so those changes should be applied on top of it, and only be the required changes to complete the porting:
https://phabricator.kde.org/source/cirkuit/history/frameworks/
Also, translation should *not* imported. We maintainer them separately and there are already some of them. Please keep them out.
tl;dr please recheck the status of the frameworks branch of cirkuit and complete the work there.
Comment Actions
Dear Luigi,
I should inform you that I've been in touch with Andreas Sturnlechner (you were copied in) - who has pointed out that there is a KF5 version already. It's a pity I did not discover this earlier - but I am new to a number of the software tools, including GitHub.
https://github.com/kmorwinski/cirkuit/tree/frameworks
A significant difference between the versions is that the "frameworks" kmorwinski version uses KDELibs4Support, whereas the version that I produced does not. I'm sure that the authors of the "frameworks" version are more experienced than me and will have written better code. I had lot of learning to do as I had not used KF5 or cmake before. On the other hand, I am a scientific user, and I have made a small number of changes that in my view make it work better.
When I am back from holiday I can put a little effort into comparing versions (the Meld program is very helpful for comparing source files). A general statement of "release focus" and an overview of code changes would be straightforward - but presenting changes atomically (as Andreas suggested) so that they can be reviewed individually would be rather onerous .. especially if intermediate versions that can be compiled are needed as "frameworks" uses KDELibs4Support.
I have been a frequent user of cirkuit (diagrams prepared with cirkuit are in several of my papers) and would like to help - but I think some thought into the best strategy is needed. We have to decide whether it's worth trying to merge the two versions - or just stick to "frameworks" if it works well. Either way, better signposting to a KF5 version of cirkuit is needed.
Best regards,Andrew.
Comment Actions
Yep, I'm aware of that, @asturm kindly told me about this and copied me in the answer.
A significant difference between the versions is that the "frameworks" kmorwinski version uses KDELibs4Support, whereas the version that I produced does not. I'm sure that the authors of the "frameworks" version are more experienced than me and will have written better code. I had lot of learning to do as I had not used KF5 or cmake before. On the other hand, I am a scientific user, and I have made a small number of changes that in my view make it work better.
That's a minor issue: as you did a complete port to KF5, you are certainly in position of applying the missing bits to the existing codebase to remove the usage of KDELibs4Support.
When I am back from holiday I can put a little effort into comparing versions (the Meld program is very helpful for comparing source files). A general statement of "release focus" and an overview of code changes would be straightforward - but presenting changes atomically (as Andreas suggested) so that they can be reviewed individually would be rather onerous .. especially if intermediate versions that can be compiled are needed as "frameworks" uses KDELibs4Support.
It may be onerous, but that's a general rule: big code dump are not easy to review and makes life more complicated when tracing back the history to understand what happened. Moreover, this specific repository is already partially ported, so the missing changes (removing KDELibs4Support, adding new features) will need to be for sure smaller.
I have been a frequent user of cirkuit (diagrams prepared with cirkuit are in several of my papers) and would like to help - but I think some thought into the best strategy is needed. We have to decide whether it's worth trying to merge the two versions - or just stick to "frameworks" if it works well. Either way, better signposting to a KF5 version of cirkuit is needed.
A Frameworks version is needed, and that's the reason why other people invested time on the frameworks branch, and I see no contingent reason to throw away the existing work.