Why Gtkmm Over Qt? · Issue #413 · Giuspen/cherrytree - GitHub

Skip to content Dismiss alert {{ message }} giuspen / cherrytree Public

• Notifications You must be signed in to change notification settings
• Fork 470
• Star 3.5k

• Code
• Issues 989
• Pull requests 1
• Actions
• Projects
• Security
• Insights

Additional navigation options

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom Why gtkmm over qt? #413 Open ghost opened this issue Oct 19, 2018 · 3 comments Open Why gtkmm over qt? #413 ghost opened this issue Oct 19, 2018 · 3 comments Labels question topic: install\running\future

Comments

Copy link

ghost commented Oct 19, 2018 • edited by ghost Loading

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. Either you code the GUI by hand or you switch to Qt and use QtCreator. IMO C++ is a mess that also has its part on why gtkmm is so hard. 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?

All reactions Copy link Owner

giuspen commented Oct 20, 2018 • edited Loading

Good point @lnieblar let me clarify my point of view: 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. You can use https://glade.gnome.org/ which is pretty good; cherrytree was using it but at the moment I rather use code 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.

👍 2 kettenfett and aviallon reacted with thumbs up emoji All reactions

• 👍 2 reactions

Copy link

manad777 commented Dec 12, 2018

@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.

👍 4 kakyoism, gouthamkrishnakv, aviallon, and kinten108101 reacted with thumbs up emoji All reactions

• 👍 4 reactions

giuspen mentioned this issue Jan 16, 2019 Best way to copy a webpage into CT and or improve HTML copy paste #450 Open Copy link

kakyoism commented Aug 26, 2019 • edited Loading

@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?

All reactions txe added question topic: install\running\future labels Feb 10, 2020 thdoan mentioned this issue Apr 29, 2024 why continue with a tool based on completely outdated technologies that struggles to continue implementing functionalities of Obsidian #2420 Open Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment Assignees No one assigned Labels question topic: install\running\future Projects None yet Milestone No milestone Development

No branches or pull requests

4 participants You can’t perform that action at this time.