This is very exciting. Here is the APK I downloaded. And the associated discussion.

It even already seems to support stylus input which is very exciting seeing as there has been talk of porting RNote to Android.

  • ExLisper@lemmy.curiana.net
    link
    fedilink
    arrow-up
    7
    arrow-down
    4
    ·
    1 day ago

    I tried using GTK with C, JavaScript and Rust and the experience was always terrible. The tools, the documentation… C is just sooooo old and GTK doesn’t translate well to Rust. For me GTK is great for Window Manger level tools that need to be small, super fast and are fairly static (you don’t add new features do settings app or clock widget that often). I definitely wouldn’t do cross platform apps in it.

    • illucidmind@programming.dev
      link
      fedilink
      arrow-up
      10
      arrow-down
      1
      ·
      1 day ago

      First, what do you mean by “C is just so old”? That seems like a language problem, not a GTK problem. Tbh, when it comes to documentation, you’re likely better off with C as the official GTK docs targets the C API (https://docs.gtk.org/gtk4/).

      Also, what do you mean by “it doesn’t translate well to Rust”? Because, Rust, like other supported langs like Python, have bindings that are equally well-documented to an extent. I haven’t used the Rust binding but I’ve used the Python binding extensively and there are references to all the APIs (https://lazka.github.io/pgi-docs/)—same with Rust (https://gtk-rs.org/gtk4-rs/).

      Lastly, I can understand not using GTK for cross-platform apps, but not for the reasons you mentioned. While GTK’s primary target is Linux, you can technically still make it cross-platform.

      • ExLisper@lemmy.curiana.net
        link
        fedilink
        arrow-up
        4
        arrow-down
        2
        ·
        1 day ago

        By “C is so old” I mean it lacks a lot of features modern languages have. Proper linting, code formatting, dependency management, version management, virtual environments, modules. Yes, you can solve some of it with docker but it’s terrible compared with Rust for example.

        By “it doesn’t translate well to Rust” I mean that GObject doesn’t translate well to Rust structs so you end up with weird structures split into multiple modules and terrible code overhead. Compared with modern UI frameworks it’s just not ergonomic to work with.

        Yes, I know GTK supports multiple platforms but if I want to develop for desktop and mobile I had way better experience using Tauri+Leptos. It’s not just about having some bindings and some docs for it. It’s about how much effort does it take to set it up and figure out how to implement specific functionality. Good docs, good tools good compiler and readable code for the framework help a lot.

        • illucidmind@programming.dev
          link
          fedilink
          arrow-up
          7
          arrow-down
          1
          ·
          edit-2
          17 hours ago

          Your statement about C is still mostly wrong. First, linting isn’t typically a built-in feature for many languages; you mostly depend on external tools or IDEs (for C/C++, CLion and VSCode with specific extensions solve this). A similar occurrence is seen in formatting, where, except for a few languages like Rust and Go (with officially maintained formatters), you still have to depend on external tools or IDEs. For dependency management, it is well-known that C/C++ lacks an official package manager, but there are well-tested third-party package managers such as conan (https://conan.io/) and vcpkg (https://vcpkg.io/). Another benefit is the project-local support in both package managers (although it is more robust in Conan), which effectively addresses both the version management and virtual environment issues you raised. You don’t always need virtual environments anyway (Rust doesn’t use one either).

          I haven’t used the Rust binding, so I don’t have direct experience with this and may not fully understand the pain points. However, a glance at the docs shows the Rust binding and trait-based pattern still does the job effectively. I don’t understand what you mean by “weird structures split into multiple modules”, as you’re just reusing built-in structs like you would use a class in the Python binding, for instance. So I don’t see the problem.

          Well, mobile support for GTK is currently experimental, so there’s that.

          • ExLisper@lemmy.curiana.net
            link
            fedilink
            arrow-up
            2
            ·
            edit-2
            3 hours ago

            Of course linting and formatting is not part of the language. Of course you can install extensions in some IDE that will handle it. Conan looks great but I never saw a project using it and when I was asking C devs about dependency management no one mentioned it. I checked dozens of GTK projects looking for some decent template to copy and didn’t find anything remotely “modern”. All projects I see simply use meson/ninja, install deps on system level, don’t provide any code formatting or linting guidelines. Most don’t bother with any modules and just dump all source code into 100 files in src. And I’m talking about actively developed tools for Gnome, not some long forgotten ones. For me the big difference between languages like C and Rust is that every Rust project uses the same formatting, linting tools, uses modules and proper dependency management while most C projects don’t. Because it’s old. Because a lot of C devs learned programming when it wasn’t a thing. Because a lot of C project started when those tools didn’t exist. You can probably start a new C project in ‘modern’ way but when I was trying to do it there were no examples, no documentation and when I asked C devs I was told that “you just do it like always”. In modern languages the default way is the “modern” way.

            This is how you declare a new component in gtk-rs:

            glib::wrapper! {
                pub struct MainMenu(ObjectSubclass<imp::MainMenu>)
                    @extends gtk::PopoverMenu, gtk::Popover, gtk::Window, gtk::Widget,
                    @implements gtk::Accessible, gtk::Buildable, gtk::ConstraintTarget, gtk::Native, gtk::ShortcutManager;
            }
            
            impl MainMenu {
                pub fn new() -> Self {
                    Object::new(&[]).expect("Failed to create `MainMenu`.")
                }
            }
            
            
            #[glib::object_subclass]
            impl ObjectSubclass for MainMenu {
                const NAME: &'static str = "MainMenu";
                type Type = super::MainMenu;
                type ParentType = gtk::PopoverMenu;
            
                fn class_init(klass: &mut Self::Class) {
                    klass.bind_template();
                }
            
                fn instance_init(obj: &glib::subclass::InitializingObject<Self>) {
                    obj.init_template();
                }
            }
            

            This is how you declare a new component in Leptos:

            #[component]
            fn App() -> impl IntoView {
            
                view! {
               <div>test</div>
                }
            }
            

            That’s what I mean by “it’s not ergonomic”.

            • illucidmind@programming.dev
              link
              fedilink
              arrow-up
              1
              ·
              28 minutes ago

              Well, for a modern approach to development in C, you may have to be creative and not rely on ready examples, but it’s still doable. A lot of the C issues are at the “conventional” level and can be solved if you just do things a little bit differently (e.g. nothing stops you from modularising source/headers files even though C doesn’t enforce this at the language level).

              I can understand the “ergonomics” you speak of in Rust but it’s not very surprising in that aspect especially given that C faces same challenge (and is even more verbose). The GObject system seems to map well with languages that favour the OOP style (built-in classes, inheritance etc) like Python. So yeah, on that, I understand ;)

    • subarctictundra@lemmy.worldOP
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      edit-2
      1 day ago

      I definitely recommend using Vala for Gtk as it was tailor made for it. It’s built on top of the object system that Gtk uses so the API fits in to the language flawlessly, unlike Rust. It even has its own website for browsing the Gnome APIs https://valadoc.org/

      • ExLisper@lemmy.curiana.net
        link
        fedilink
        arrow-up
        3
        arrow-down
        2
        ·
        1 day ago

        I read about Vala but a language that compiles to C seemed icky to me. I don’t know, maybe it solves all the issues that C has. Maybe I will give it a try one day.

        • subarctictundra@lemmy.worldOP
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          15 hours ago

          I think the saving grace is that you never actually see the C (it’s piped straight in to GCC), so it might as well not exist. C GObject code has a lot of boilerplate and I like to think that Vala is the programming language that GTK programmers are actually thinking in when they write their C. Vala is essentially a compression of the C code with less room for errors.

          • ExLisper@lemmy.curiana.net
            link
            fedilink
            arrow-up
            1
            ·
            7 hours ago

            Interesting, I didn’t realize Vala was designed specifically to help with GTK. It could be a skill issue but I found the entire ecosystem really hard to understand. It’s like all documentation is written assuming you already know half of it. “Vala uses the GObject system”. Yeah but I’m just deciding which language to use to learn GTK, I don’t know what GObject is… Now that I understand it all better I would probably just use Vala and stick to GTK. Instead I switched to Tauri+Leptos+Thaw and it was a joy in comparison. Documentation was clear and I was just able to link my app to local framework code and debug whatever part I wanted. I was able to fix bugs in Tauri in first weeks of learning and I contributed quite a lot along the way.