Bringing CherryTree to C++

[txe]

Hi @giuspen As my first step, I consider porting menus.py. It looks like a good task to start, so I can begin working on it if you don't mind.

[txe]

It looks like Gtk::TextIter::forward_to_tag_toggle doesn't work, it just moves an iterator to the buffer end and, as a result, our parser (converter to html) is not working and outputting a plain text. It was OK when I was working on the clipboard functionality (which uses html).

I checked on Ubuntu and Manjaro Arch, the same thing. It's easy to see by coping text into clipboard and inserting somewhere.

[giuspen]

Gtk::TextIter::forward_to_tag_toggle is used also to save the cherrytree document rich text nodes to disk and that does work, I have tested recently. I would just try saving a rich text node and re opening if that is ok you can compare with how you are using in the html exporter. If it is code nodes you are talking about, be careful there's a command to ensure the highlighting of the whole buffer to be run before, don't remember if on the buffer or the view at the moment

[txe]

Yeah, thanks! It was good to know that forward_to_tag_toggle was working. Turns out there were two bugs, one with wrong iter offset, another with clipboard. I've fixed them.

[giuspen]

You're a star @txe you'll have to let us know at least roughly where are you based 😊

[txe]

I'm from Russia :) BTW, can you give an instruction how to build exe file of pygtk version for windows? Other files, I think, I can take from the portable archive, or it is not that simple?

[giuspen]

I'm studying Russian every day on my phone with Duolingo, my wife is Ukrainian :) In order to build the cherrytree Pygtk2 exe you should first be able to run it from the python source code first http://giuspen.com/cherrytreemanual/#build-windows then you build with "python setup.py py2exe" and yes you can merge the files with the portable archive. It is not simple to set up all though, I can build any exe version for you if you want or if you still need to be independent I can upload my virtual box virtual machine with a windows xp that I use to build all the versions.

[txe]

Wow, that's cool! We can use some Russian here if there is a desire :)

[giuspen]

😄 it is still very limited but surely I would be able to order something to eat at least 😅

[txe]

Hi @giuspen I'm doing some nice changes in pdf print, so in case you're going to release a new version, wait a bit :)

[giuspen]

Hi @txe sure thanks I'm not going to issue a new version shortly

[txe]

Hi @giuspen I sent you an email :) About other things, how about brushing up the github repository? If it is convenient for you, you can add me as a collaborator, while I can:

• sort out issues, add tags and remove outdated ones
• add a pinned issue with the C++ progress and other things to make overall appearance polish. I understand it is not much essential, but nice looking things always cheer up.

[giuspen]

Hi @txe, sure, collaboration invitation on its way! If you will still have time it would be great if you can also have a look at the porting of the undo/redo machine, that is the latest big missing feature in the Gtkmm3 version, others are less time consuming. If too much for you at the moment don't worry I'll try and start it ASAP but may take again one or two weeks before I can do that.

[txe]

Don't worry, I'll take it right away after finishing txt import.

[txe]

Hi @giuspen , I'll be on vocation until the next week.

[giuspen]

Hi @txe have a good rest ;)

[txe]

Hi @giuspen, I've been loaded with work in the last week, so did a half of undo/redo, I'll keep working on it.

[giuspen]

Hi @txe excellent thanks myself I'm focusing bold and run properly on Windows

[txe]

Hi @giuspen , what else can I do for now? (except tables:))

[giuspen]

Hi @txe, would you like to try and port the code node execution functionality from Pygtk2 to Gtkmm3? Otherwise going through the Gtkmm3 top menu items

[giuspen]

Just a touch mistake. Any top menu item not working, or also trying to restore the dark theme functionality that I had to comment out because had issues.

[txe]

Hi @giuspen

Any top menu item not working,

What do you mean?

Also about icons, you changed icon names in ct_menu.cc (for example, 'gtk-open' to 'open'). Are your going to add 'open.svg' into 'future/icons'? otherwise it will not work.

[giuspen]

Hi @txe I phrased it wrong, I meant not connected, whose functionality behind the menu item click is not yet ported. I'm surprised open.csv is not there/stock not working, I will double check that later, I remember seeing the icon on the toolbar.

[txe]

I meant not connected, whose functionality behind the menu item click is not yet ported.

It's still confusing, 'Edit'->'Configuration' starts the configuration dialog.

There is no 'open.svg' icon in future/icons and the stock icon is 'gtk-open'. Or maybe my theme has 'gtk-open' instead of 'open'?

[giuspen]

Maybe all menu items are already connected to a functionality, I have to review what's left to be ported, will try and do it soon, it is easier to access the phone than the pc for me these days. If you run on your pc "find /use/share/icons -name open.*" do you get anything? All that goes to gtk stock automatically

[txe]

Hmm, I checked Icon Naming Specification and it says it should be 'document-open'. And there is a script which shows them.

[giuspen]

Oh I see. Note that I renamed the icons mainly to be sure that were available out of the standard stock for Windows/msys2. Important is that we don't have duplicates with different names but I don't mind if you want to rename few

[txe]

Sure, I rename some of them, find /usr/share/icons -name open.* -> shows nothing find /usr/share/icons -name *open.* -> shows 'document-open.svg'

[giuspen]

Great, I would like to add credit to you as a developer on the cherrytree homepage and in the help -- about dialog but don't know if you would be happy about that, please let me known

[txe]

Thanks, it would be great :)

[giuspen]

Do you want your name to be visible as well or only the nickname?

[txe]

Sure, let's use the name and maybe instead of email, github url be better? (don't want to get a lot of spam)

[txe]

It won't be new icons, gresource_to_c.py fixed my issue with them (I don't use build.sh)

[giuspen]

Ok got it

[txe]

OMG, it was a good opportunity to make an announce that we are moving from Gtk to Qt.

[giuspen]

For the first of April I hope 🥳

[txe]

Hi @giuspen , There are things to do, but maybe you bear something particular in mind which needs attention?

Meanwhile, I think about some code organizing. It doesn't need an immediate action, just to keep you informed:

• Document loading spreads thought all code CtMainWin, CtTreeStoree and others. I think it could be more straightforward and put in one file.
• Some files can be similarly named (codebox, table ->widget_table, widget_codebox) or put in one folder (widgets), or something like that.
• Move from make to cmake. Well, cmake has some benefits.

[giuspen]

Hi @txe I'm happy if you want to drive some rework/renamings, I think now would be a good moment for it. I also prefer cmake and use that at work but I read there were some issues with the internationalisation support, for this reason I started with the autotools for Gtkmm3. I would keep supporting both rather than replacing, at least at the beginning. After your reworks, I would like to raise the warning level, adding -Wextra and -Weffc++ that helped my group at work a lot to spot issues. For now first thing I will setup an installer for Windows 7+ and fix the scripts to create the Debian package so that we will be able to distribute the first alpha to get the first feedback.

[txe]

Well, the next announce is that we can't go from Gtk to Qt after that: Qt, Open Source and Corona

[giuspen]

Well I wouldn't have expected this from Qt!

[txe]

@giuspen Just to give head-ups, I'm still working on organizing code and it will take a few more days to finish. There is one thing about versions I'd like to discuss.

There will be new features one day or another which will demand changes in file formats. Supposedly, these changes will not be backward compatible and using an old version program will destroy some information in those files. To fix it, we need some version check in the program and a question is. Should we introduce it as soon as possible? Or even in pygtk version just in case it will be still around at that time?

[giuspen]

@txe what I've been doing when I completed the possibility in Gtkmm3 to write all documents types and the config.cfg, was to release a new Pygtk2 version that supports reading those peculiarities that the Gtkmm3 version requires. The current Pygtk2 can read what the current Gtkmm3 version writes. I would like to keep the possibility from a newer Gtkmm3 version to read all the older Gtkmm3 versions (sometimes with an auto conversion) and at the beginning the latest Pygtk2 version to be guaranteed to be able to read that as well. Since we will not want to keep updating the Pygtk2 version though, we may indeed mark the Gtkmm3 documents with a version at a certain point and, from the Pygtk2 version, show a message in a dialogue inviting to switch to the Gtkmm3 version to read that document if no longer supported. Here it's quite hard for me to find time to sit at the computer in lockdown with the kids, I'm so grateful you joined the project, I will try and make installers for now

[giuspen]

Consider that at the beginning people will try the Gtkmm3 version and maybe use it for few days until they realise something still doesn't work well so raise an issue and switch back to the Pygtk2 version until that bug is fixed (or that functionality is polished) this should be supported, their modifications must still be readable from the Pygtk2 version in the first phase

[txe]

Ah, yeah, I fully agree about first releases and have not intention to do otherwise (format changing, it would be total disaster). I meant, in one or two years, some poor user can (although it is not really probable) try to open a new file (with changed format) with an old version program and it can be fixed it that old version program already has checking mechanism, that's all.

[metal450]

Not relevant to the actual porting, but just some words of encouragement: SUPER excited at the prospect of an upcoming release! I've been keeping my eye on this project for just over a year in anticipation of the day I can take the plunge & escape OneNote. Sounds like it's getting close!! :)

[txe]

Hi @giuspen, Turns out html paste is not yet implemented, and I think it would be noticeable. Because you already once did it, what do you think, it would be better to use third-party html lib or some handmade parser would be enough? I checked a few html copy/paste and the data not always looks like a valid html: no header and body.

[txe]

OK, looks like libxml2 includes html parser and supposedly it can handle 'real world' html.

[metal450]

Actually, I'd like to chime in: one of the only two "roadblock" issues I found with the previous CherryTree (the main reason I was waiting for the port before migrating over) probably relates to html paste (or, formatted text paste). Per #496, font sizes were lost. Even if it's not possible to support "freely sizeable" fonts right out of the gate (ie. 10pt, 12pt, etc, like Word or OneNote), if html pasting could even generally preserve sizes I think it would be a big step forward. For example, by using thresholds, where <8 becomes html tiny, <10 becomes html small, <13 normal, and so on. Hopefully it's something that could be taken into account, if paste is yet to be reimplemented anyway :)

[giuspen]

Hi @txe yes it is definitely better to use a library, if you find that libxml2 covers that please check if the C++ wrapper https://developer.gnome.org/libxml++-tutorial/stable/ that we are already using for XML read/write can be used before proceeding with direct C API

[txe]

@metal450, yeah, it's possible to do, I'll try

[metal450]

Awesome! & again, if at all feasible, I'd lean toward retaining "true" font sizes for the best compatibility with other editors. I was just mentioning the tiny/small/normal groupings as a 2nd best choice, if the former proves too complex i.e. do to storage reasons, etc. 👍