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]

Hi @giuspen , did you try to compile tests? for some reason, it stopped working until I added '-lm ' flag. Maybe, it's just my PC going crazy/

[giuspen]

Ho @txe I built yesterday on 18.04 and found a different issue with your latest changes not building for me, we have different versions of autotools and compiler, you have probably the latest since you are running Arch if I recall correctly. That's good it has to build everywhere ;)

[txe]

Actually, I was using Ubuntu Budgie in vmware just for fun and turns out it didn't work well under heavy load; vm and keyboard freezing and there were a lot of crashes. Now, I'm on arch with xfce.

This weekend, I tried to work with 10000 nodes (100x100) to see if it's possible. There are two choke points from the view of creating/loading 10000 nodes:

• slow applying style to text in TextBuffer. When text is put into a textbuffer, that fires a signal and after all nodes are created, in an idle main event loop, signals begin to apply style to text. And it's slow.
• again, when anchors are inserted in a textbuffer, that fires a signal and after all, textbuffer starts to calculate a widget sizes. Moreover it does a few iterations for each widget and it is absolute nightmare, the program is freezed for many minutes even when nodes are not that much.

Currently, it is possible to create/load > 1000 nodes with text per second. With widgets it is not that possible. Sqlite is not a solution because any Find/Replace cause loading of all nodes with the same issue.

Anyway, I see a really simple solution (even for xml):

1. load all nodes with textbuffer without styles and widgets. This allows to use find/replace easily
2. when node is selected, apply style and widgets.

[txe]

BTW, do we need spellchecker and system tray icon in the first release?

[giuspen]

Interesting test @txe! Disappointing for me but your workaround to load without formatting (and clear the formatting when you leave the node?) May be a solution... We need the embedded widgets as well in the search though but those can also be not into the text buffer. I'm curious why do you use VMware over virtual box? I've always been using the second for personal free use. About the spell check and system tray since we're not too far it may be worth to try and include it so the features are really complete (except for the imports). About the imports I was thinking that at least initially we could use a hybrid c++ and python3 to reuse the existing code and have a quick solution. The python 3 code could generate a cherrytree document that then the C++ reads

[giuspen]

I forgot to mention that the windows standalone package and installer are pretty much there but there is an issue I've spotted (with the file paths, of course, pain in the neck) but I'll sort it out shortly

[txe]

There is no much reason to clear the formatting after leaving the node, the job is already done. And maybe anchor widgets have too much layers of widgets (like image inside frame inside EventBox)

I've been using vmware for the last 10 years, so it's hard to recall, maybe initially vmware was more stable than virtual box (my former coworker says Kompas-3D (CAD), we worked on, crashed in virtual box). And I have a couple of old images, I use from time to time, no much sense to convert them.

The problem with imports is that I don't have files to test these imports. otherwise it's not hard to port the code, it's not much there.

[giuspen]

Well if you think there's no much there in the imports you have no excuse not to port it before the first release 🤣 I reckon it's thousands of lines. We can fix the issues when users will try unsuccessfully the imports and will send over their data to reproduce

[txe]

@giuspen , can you add support for trevis ci? it's super easy, I left the link how to do in #738

[giuspen]

Sure @txe I'll look at that this evening

[txe]

Thank you!

[giuspen]

Thanks to you my friend, should be all done.

[giuspen]

Just a note on the filepaths. If you notice Glib is never using the Glib::ustring for the filepaths. See for example https://developer.gnome.org/glibmm/stable/group__MiscUtils.html - I've been doing the same but in the end you are the best person to verify issues doing that since you do use a non ascii character set. Was the case that you found problems using plain std::string? I'm talking about this because having some issues with filepaths on windows even though I have not yet identified the cause. An example is ct_storage_control.h and Glib::ustring get_file_name() { return _file_path.empty() ? "" : Glib::path_get_basename(_file_path); } while the API is std::string Glib::path_get_basename(const std::string& filename)

[txe]

https://developer.gnome.org/gtkmm-tutorial/stable/sec-basics-ustring.html.en

There is a difference when you have to operate with symbols in a string like find or replace. std::string doesn't know about multibyte unicode symbols and works like it is one byte strings. As long as you just copy and compare data it should be fine. When you give std::string to Glib, it is also fine because they know it's unicode.

I suppose , they return std::string because their C analog also return char*, like raw data.

You may have problem in windows, because they use utf-16 there sometimes.

[txe]

Glib::ustring is just wrapper over std::string and has some functions to operate symbols instead bytes.

[txe]

Looks like a good idea to try it myself on windows.

[giuspen]

No rush for you to look at windows, surely eventually your use case is important, but for now I can start fixing the issues I see with my UK English system.

[txe]

@giuspen thanks for adding travis! it's already run into compilation issues :) I tried a bit cherrytree on windows, the default theme looks surprisingly good.

The bug with the disabled toolbar affected both OS, I'll fix it later. I started working on gspell, do we need a compiler option to build cherrytree without gspell or whatever?

[txe]

And I'm not sure, do need some c++ wrapper for gspell (it's c library)? there is no gtkmm for it.

[giuspen]

@txe It was a good idea this of Travis, thanks for pushing for it! 😉 I knew you couldn't resist and try windows 😄 I'm happy that you have a feel of the windows version too though! I also was surprised at how good the native windows theme is! I would not worry about providing macros to build without gspell, it's not such huge library. About making a wrapper just see how it is, if you find efficient to add a class that exposes gspell or not.

[txe]

Hi @giuspen , what do you think about possibility to cut corners and release a version for linux? We can postpone Windows installer and imports for a week or two, and focus on issues that prevent a linux release. I sure that will make users happy and gives us some boost and confidence for finishing other things properly.

[txe]

Or we can make a test version package and ask some users to test it

[giuspen]

Hi @txe I agree in starting to package a Linux version only for testers (no rush for the windows package) but I would not advise this to users that want a stable version, for that there is the snap package and I was considering trying to set up a flatpak myself.

[txe]

Ok, how do we start? So far, I have the following issues to fix in my list:

• changing node type
• autosave
• justification
• 7zip lib (pass params as values, not just a string, plus clean up output in console)
• vacuum
• remove global vars (e.g. Find/Replace)

[giuspen]

I would rather have your list completed, then I would do some testing myself only and report the issues/help fixing and then go with an alpha. My concern is to unnecessarily start to get bombed with known issues. In the meantime I will add packaging scripts. If you really want to start before the end of your list let me at least try and setup the proper packaging for Ubuntu this weekend

[txe]

Good, sounds like a plan. I'm going to finish my list (take no more than 2 days) and will wait for your feedback.

[giuspen]

You're a star!

[txe]

You too! To keep the project without giving up, it is something :)

[SadE54]

Nice to see such a winner team for the upcoming c++ release 👍 I can't wait to test it! 😊

Le ven. 24 avr. 2020 à 19:20, txe notifications@github.com a écrit :

You too! To keep the project without giving up, it is something :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/giuspen/cherrytree/issues/444#issuecomment-619143020, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAV62MHMBPTK3NNA3XEJLDTROHC63ANCNFSM4GOEKWDQ .

[txe]

@giuspen , I have fine icons on the toolbar/menu and on the node tree, but strange ones which are loaded by _pGtkIconTheme. about dialog with app icon changing highlighting Do you have the same issue?

[txe]

It looks like Gtk theme has cherrytree icon and it has more priority than cherrytree.svg

[txe]

I remember you renamed some icons, I guess, because of that issue. Maybe we need to use prefix ct_ to easily distinguish them?

[giuspen]

@txe I think it is a good idea to prefix our icon stock, is was indeed a similar issue

[giuspen]

Since I'm looking at the packaging and one part of it is the command line manual, have you already looked at supporting the command line arguments of the Pygtk2 version? If not, do you want me to look at that?

[txe]

Ok, you can take it)

[giuspen]

Hi @txe about our discussion the other day about std::string on the filepath, if you see https://developer.gnome.org/glibmm/unstable/group__glibmmEnums.html#gabd6606988f30170f2e53b2b121f2b219 for the command line argument types you spot among the supported types:

BOOL | bool
STRING | Glib::ustring.
INT | gint32
FILENAME | std::string
STRING_VECTOR | std::vector<Glib::ustring>
FILENAME_VECTOR | std::vector<std::string>
DOUBLE | double
INT64 | gint64

very explicitly it is using the plain std::string for the filepaths. Some years ago, before starting the cherrytree porting, I remember that I've been fighting because the Glib::ustring was trying to do unnecessarily encoding/decoding crashing my code

[txe]

Ok, lets use std::string for file paths, I checked a couple of other projects, they do the same, so , I guess, it's working fine

[txe]

Hi @giuspen , I saw the issue with linker on travis, but for some reason I couldn't reproduce it on arch and ubuntu 20, I almost installed ubuntu 18, but found out you fixed it :)

I fixed my list of issues, so am going to wait for your feedback.

BTW, you need to try QtCreator with cmake/ninja! QtCreator works with cmake right out of the box, no issues, no hustle, And making cmake to build the project by ninja instead of makefiles speeds up building process by times.

[giuspen]

Hi @txe, could you continue the work I started with the command line if you have some time? If not no worries there's no huge rush the snap package works very well. I'm not sure I will be able to get back on it before the next weekend while I will try and test the multilanguage if I find some time and start testing your work.

Also visual studio code has cmake support and it works very good on linux. I have some concerns about cmake support for the internationalisation but we'll find out very soon.

I wasn't sure you saw Travis failure :) I would like to add windows/msys2 as well to Travis I read it should be possible

[txe]

Sure, I'll take on the command line. What do you mean by 'the internationalisation support'? generating pot files?

[giuspen]

No the pot is generated via a shell command, I was thinking about the .mo files but those are accessed in runtime it shouldn't really be an issue, I'll verify soon. Note what I've done is parsing the supported switches (try cherrytree --help) and only printing if you pass a node name (-n nodename), nothing else unfortunately. Note you will find a callback where I'm returning -1 that strangely is to say all good and keep going, see the Gio::Application reference the Gtk::Application is inheriting from

[txe]

BTW, when I started snap store, cherrytree was on the first row Editor's Picks. Does it mean that the program is that popular, or Canonical is just spying on me? :)

[giuspen]

Morning @txe, while I confirm we can go public without the imports from other note taking apps, I think we should support the first 5 menu items which are:

• cherrytree file
• plain text file + folder
• HTML file + folder Just in case you are getting bored 😄

[kettenfett]

BTW, when I started snap store, cherrytree was on the first row Editor's Picks. Does it mean that the program is that popular, or Canonical is just spying on me? :)

CherryTree is right on the store front of Snap's website (https://snapcraft.io/store) right now. I have never visited that page before. I'm a windows user, so there you go...

[txe]

Hi @giuspen ,

I want to add support for reading .css and .js files from /usr/share/cherrytree. For linux (I'll skip windows for now), there is g_get_system_data_dirs (XDG_DATA_DIRS),

What else directories do you want me to check?

The structure of dirs wil be the same as for pygtk?

[giuspen]

Hi @txe if you see Makefile.am you can find all the directories that are going to be installed and what's inside there. You should not use /use/share though but the macro DATADIR exposed from the autotools because that may vary (still see Makefile.am). You can also look at https://github.com/giuspen/cherrytree/blob/master/future/data/manual-install.txt more human readable.

[txe]

Ok

[giuspen]

Actually I'm realising something is still missing, for sure the export to html stuff currently inside of the glade folder, that is also to be added. Note only two syntaxes are out of the new gtksourceview4

[giuspen]

In fact I misunderstood you in the first place the html stuff was exactly what you were interested in, I'm sorry it was a hard day. Those files are to be duplicated into future/data and Makefile.am modified to install them. Note that we also want to support running from the sources folder with those files local and not on the filesystem same as we were doing in Pygtk2

[giuspen]

I can do this just not sure this evening I can find the time