Cherrytree: Why gtkmm over qt?

[ghost]

1. Qt is the best option because it's a C++ native library. GTK+ is a C library and gtkmm is a C++ wrapper that leads to some problems... A lot of people just don't like how it feels.

2. Either you code the GUI by hand or you switch to Qt and use QtCreator.

3. IMO C++ is a mess that also has its part on why gtkmm is so hard.

4. https://www.youtube.com/watch?v=ON0A1dsQOV0

Gtk is badly documented. The Gtk community is indifferent to issues at best and gives non answers or abuse to questions. Gtk is primarily a GNOME project, cross platform (anything outside GNOME) is ugly, buggy and not a priority.

I really like this project and wanted to help expand it. Finding the ridiculous 5K LOC core.py file with repeated functionality was very depressing so I was glad that a transition to C++ was occurring, but I've noticed the progress is slow. Of course you've mentioned your family keeping you busy, but I can't also help but feel like GTK is part of the problem...

What am I not seeing in gtkmm that you're seeing?

[giuspen]

Good point @lnieblar let me clarify my point of view:

1. Agree that wrappers lead to problems, that's why I'm steering away from python bindings. C++ wrapping of C anyway is not that bad and it is up to date with the upstream C. Furthermore you can even use directly the C underlying if necessary.
2. You can use https://glade.gnome.org/ which is pretty good; cherrytree was using it but at the moment I rather use code
3. C++ has been improved a lot with latest C++11/14/17 while in the past it was mandatory to use boost libraries and I agree Qt was light years away (still is way ahead)
   GTKmm is well documented IMO, I can help pointing in the right direction, but I agree Qt would have been a better choice overall especially for the better support I would have had from other developers like yourself and better cross platform support.

The main reasons why I ended up choosing GTKmm:

• QtScintilla does not cover all syntax highlightings that GTKSourceView supports
• I didn't find a way to embed into the text the widgets that I wanted, leading to the impossibility to provide the same codebox experience while for images and tables that would have worked fine (actually better for tables)
• This porting job is quite harsh and urgent and I would like to deliver something that at least at the beginning will be the exact same functionality of the latest python version with the benefits of:
  * better coding using object orientation (many years of experience after I first started cherrytree. I agree the coding of cherrytree is a pretty bad mess)
  * the speed and robustness of C++ over python
  ** unit testing core functionalities

Furthermore for me porting from python/GTK2 to C++/GTK3 is quite straightforward. I plan to finish the foundations in few weeks and then it should be easier for people like you to help port single features.

[manad777]

@giuspen , one recommendation to keep a clean separation of UI and functionality, is to write a command-line client at the same time as you write the GUI. It might seem like more work but really a basic CLI UI isn't much code if you use a 3rd party library, and it'll pay for itself in the long term by forcing a clean design on you. This would also prepare the codebase for a Web UI version if it was on your future todo.

[kakyoism]

@giuspen , one recommendation to keep a clean separation of UI and functionality, is to write a command-line client at the same time as you write the GUI. It might seem like more work but really a basic CLI UI isn't much code if you use a 3rd party library, and it'll pay for itself in the long term by forcing a clean design on you. This would also prepare the codebase for a Web UI version if it was on your future todo.

@manad777 I couldn't agree more on this idea of front/backend separation. Further along this route, do you recommend writing the GUI as a separate app, using IPC for the front/backend communication, or the front/backend can share a lib of functionalities so that the GUI version is simply a super-set of the CLI version?