11 May 2017 at 23:35 #124297
Dear cherrytree users, this is to update you on what I’m working on and what are the plans for the near future.
The library that cherrytree is currently using, pygtk (python2 and gtk2 static bindings) is old, unsupported and causing more and more problems as new versions of linux and windows operative systems are released.
For this reason, after releasing 0.38.0, I put all my efforts to the porting to python3 and gtk3, also known as pygobject or pygi (see https://wiki.gnome.org/Projects/PyGObject/IntrospectionPorting).
The development is happening on the git branch named ‘pygi’.
At the moment I’m stuck on a blocking issue that is the lack of availability via python of a key function for cherrytree, gtk_clipboard_set_with_data (), (https://developer.gnome.org/gtk3/stable/gtk3-Clipboards.html#gtk-clipboard-set-with-data)
I tried to use a binding package from sugarlabs https://github.com/sugarlabs/sugar/commit/b9707272f752a0fda35b3898761ab037fd5f95ac SugarExt.clipboard_set_with_data() but that doesn’t seem to work, or at least I failed to have it working in ubuntu 16.04 LTS and package gir1.2-sugarext-1.0.
I actually got stuck on the same issue in 2011 (see http://python.6.x6.nabble.com/pygtk2-to-pygobject-introspection-td1941553.html) when for the first time I attempted the porting, and after 6 years still I don’t see a solution.
Basically without this function available, the copy/paste of rich text doesn’t work and only the plain text is available, all the formatting is lost.
Any help from developers in the pygi branch would be highly appreciated.12 May 2017 at 19:43 #124300
Were you to learn enough C, is information and functionality within Python3 available that would allow you to code your own “gtk_clipboard_set_with_data ()”?
Is it possible?
If so, I’d imagine that similar issues in future releases of GTK would be more easily met.
I also imagine that such an effort would require learning a debugging platform for use in tracing 0.38.0’s execution.
Elsewhere, I’ve said it before, and I’ll say it again… Thank you for cherrytree.
14 May 2017 at 19:42 #124302
- This reply was modified 2 years, 3 months ago by AlanWalker.
Have you ever considered to move from GTK to Qt ?
PyQT is a popular Python binding for QT. QT seems more stable, have more features and has a lot better cross-platform support.
The developers of my favorite Linux distribution(Solus OS) are moving Budgie(the desktop environment) from GTK to QT, because of the issue with GTK.
I read that some time ago even Linus moved his app from GTK to QT and also other important applications.
I found copy/paste operations in QT: http://doc.qt.io/qt-4.8/qclipboard.html and the python binding: http://pyqt.sourceforge.net/Docs/PyQt4/qclipboard.html
I never used GTK and also I didn’t do any serious app with QT, my opinion is based only on others experiences and news.15 May 2017 at 00:08 #124306
In the last days I’ve indeed been thinking about a migration to PyQt5. I actually know QT since I already worked for years in QT4 via both C++ and Python and I know how good it is.
I exclude taking care personally of the missing bindings between gtk3 and python because that widens too much the effort, keeping cherrytree up is at the moment all I can take care of in my free time.
I considered porting to gtkmm3 (so just python to C++) since I already developed in gtkmm3 but then I decided that because of the limited free time I must stick with python or I won’t be able to keep up
I will update on the forum about the status of the porting…15 May 2017 at 21:22 #124307
in the meanwhile here is the bug I raised: https://bugzilla.gnome.org/show_bug.cgi?id=78259522 May 2017 at 07:31 #124313
Good luck I believ3e in you. IO have spent hujndreds of hours developing a notebook for my students based on your program, and appreciate everything. https://www.dropbox.com/s/dm6kh773cnr9tol/TEAM%20ALL%20TEACHER%20V10.ctb?dl=0 here is what I am working on…. thanks for everything….2 June 2017 at 15:50 #124317
On 29 May 2017 at 06:06 ClarkeCC asked if you had a github listing for this project.
This is just a suggestion. If you move the project to to github there is a good chance you will get a lot more input and help from many experienced programmers, thus accelerating the development of Cherry Tree.6 June 2017 at 00:25 #12431810 June 2017 at 14:46 #124325
Very good project !
The only black point for me is that I can’t export to odf file like the pdf export.
Do you think if it’s will be possible for a next release ?11 June 2017 at 00:27 #124327
The next major release will have no new feature (may even have something less) and will just run with different libraries, I’m still experimenting before starting the porting28 June 2017 at 15:34 #124340
Just in case,
did you consider the possibility of using PySide2 (which is for QT5)?
It is compatible with Python 2.7 which would allow you to focus exclusively on the library change now and to cross over to Python 3 at another moment.
https://wiki.qt.io/PySide2_GettingStarted29 June 2017 at 23:21 #124341
Actually I prefer python3 to python2 so considering the importance of QScintilla for the syntax highlighting I would go for PyQt5.
After experimenting with PyQt5 though I didn’t find a solution for the porting of the codeboxes without losing the syntax highlighting.
With Qt it seems quite complicated to embed objects into the text (I need a Qscintilla box into the rich text) and for this I may stick with GTK3 and port from python to C++ (gtkmm3)9 July 2017 at 00:29 #124347
I’m progressing writing c++ code using glibmm, libxml++, sqlite3 so at the moment the gtkmm3 path is the one I’m pursuing30 July 2017 at 00:04 #124366
If major changes are taking place for the next version, have you considered using cefpython and HTML5 rich text as an alternative to the current content section and the rich text format? cef embeds into gtk and qt pretty easily and the clipboards would(I think) be handled by Chromium.
- Clipboards for free
- Potentially more advanced styling/embedding possible
- Easier to implement a web version in the future since the encoder would not have to be juggled
- GTK3 isn’t exactly cross platform friendly
- Security? I haven’t though through the implications yet of what data in the current version could do when displayed using something backed by chromium. It should be sanitized enough to not matter but bugs happen
- A large amount of work needed before the first usable/upgradable version would be functional
- Upgrades would likely be oneway only
17 August 2017 at 23:42 #124376
- This reply was modified 2 years ago by rednixon.
@rednixon On the contrary at the beginning there will be no changes or the minimum of changes possible, the goal is that the user will move seamlessly from the Python cherrytree GTK2 to the C++ cherrytree GTK3. For this very reason I’m sticking with GTK rather than moving to Qt where I could not ensure the continuation of some features.
You must be logged in to reply to this topic.