For the past few months I have been working on a simple windows notepad like text editor. It’s nothing special, but when I first switched to linux I looked around and it took me a while to find leafpad. Unlike leafpad however, Janus uses gtk3, a much more modern toolkit then gtk2, it can display and modify binary data, and it can highlight code syntax for most popular languages. Feel free to check it out on the github.

    • satyrn@lemmy.worldOP
      link
      fedilink
      arrow-up
      14
      ·
      edit-2
      8 months ago

      The main thing is that gtk3 is a little more stable and available for now. Gtk deprecates tons of functions seemingly at random, and I don’t want to have to constantly re-code my project as they deprecate things. As for availability, Gtk3 is shipped everywhere as 3.24 rather than different distros having different versions, gtksourceview4 is shipped on older distributions then gtksourceview5 (meaning more compatibility), and if I ever wanted to port to other operating systems Gtk4 would be much harder than 3. Finally, before the starting Janus I was under the impression that no gtk4 apps could be themed, but I have since learned that that is not the case. Knowing what I do now, once they iron out more of the kinks I will definitely port to gtk4, but first I want to make sure everything works well.

      As for binary editing, I took a very different approach to other editors. Most either convert the binary data to a code page (very confusing and nearly impossible to edit) or use escape characters, which is not a bad solution by any means but looks increasingly worse with the entropy of the data. I eventually came up with this approach, which I think maintains the simplicity of a notepad editor while allowing the functionality I meant to include.

    • refalo
      link
      fedilink
      arrow-up
      6
      arrow-down
      1
      ·
      8 months ago

      even more obvious question, why not Qt?

      • satyrn@lemmy.worldOP
        link
        fedilink
        arrow-up
        10
        arrow-down
        1
        ·
        8 months ago

        This was mainly because I don’t know C++ but I do know C.

        Outside of that, I generally sway more towards gtk apps then qt apps and I use Budgie, so it fits in with my desktop better. Gtk also seems to be more widely used than Qt on linux. And Qt seems to delegate more of its functionality to standalone libraries, which means more dependency tracking which I am very opposed to, whereas Gtk packages one library that encompasses most of the libraries functionality (although I don’t know enough about qt to be sure if this is the case).

      • Ramin Honary@lemmy.ml
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        1
        ·
        edit-2
        8 months ago

        As someone who is trying to develop my own Linux destkop apps, I can tell you that the day that I switch to Qt is the day Qt provides a feature that works as well as GObject Introspection (GI) does for Gtk. GI creates a cross-platform database of objects, properties, and signals, for auto-generating language bindings, so you can customize your Gtk programs with scripting languages (Python, Lua, Vala, JavaScript, Scheme). It is a relatively simple task to bind any programming language to GObjects thanks to GI.

        Qt does have a QMetaObject system which is similar, but C++ is a difficult language to bind to on most operating systems because of how native language functions are labeled in the library code – names are “mangled”, a hack to work around the miss-match between object libraries features (.so or .dll files), which do not provide the ability to “overload” functions, and C++ libraries features, which do provide this ability. The function/method overloading feature is used quite often in any C++ program. But decoding mangled names for language bindings can be very error-prone without the sort of automation that GI provides.

        As it is now, really the best way to develop Qt apps is to use C++, with Python for scripting, because these languages are the most well-supported by Qt (C++ natively, Python being the most stable and well-maintained “foreign” language for Qt). And I like neither of these two language. Gtk gives you a much larger selection of scripting language choices, even though it is programmed in C, and this is thanks to how well GObject Introspection works.

        • refalo
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          edit-2
          8 months ago

          I think your use case/justification may not be applicable to the majority of GUI app developers. I have been using both professionally for at least 15 years and IMO without a doubt Qt is so much easier to use, read and work with it’s not even a comparison. When even Linus Torvalds cannot figure out Gtk or get non-rude useful help on it and jumps ship to Qt instead, I think that says it all. Plus in comparison to Qt there are almost no commercial outfits using Gtk professionally and selling products based on it.

          • Ramin Honary@lemmy.ml
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            8 months ago

            I have been using both professionally for at least 15 years and IMO without a doubt Qt is so much easier to use, read and work with it’s not even a comparison.

            I also use Qt professionally, and it is indeed an excellent GUI library. I have absolutely no complaints with how well it is designed and how easy it is to use, and I am consistently amazed by how beautiful the results are, especially with desktop environments like KDE Plasma.

            My complaint, which is really a deal-breaker for me, is that Qt effectively forces you into using C++ and Python and/or QML+Quick. For the non-professional software I develop, I want my apps to be scriptable by end users, and I do NOT want to force them to choose between only Python or Quick as their scripting language. For building scriptable, truly cross-platform GUI apps, Gtk is the only game in town.

            Gtk is much harder to use only if you are coding in C, because it depends so heavily on the C preprocessor to hack together the infrastructure that C++ has built-in. But because it is so easy to bind scripting languages to Gtk, you only need to program a few very core features in C, the rest you can program in any scripting language of your choice. This very important feature I think is a worthwhile trade-off for making it harder to code in C, especially if you are able to code the larger portion of your application (which is almost always the case) in a scripting language like Lua or Scheme. (Although I admit, most Gtk scripting is done in Python, just as it is with Qt.)

            Plus in comparison to Qt there are almost no commercial outfits using Gtk professionally and selling products based on it.

            Perhaps, but I would point out that both Canonical and RedHat (now IBM) are both heavily invested into developing Gnome, and I believe most of the paid Gtk development has been funded by these two companies.>