• warmaster@lemmy.world
    link
    fedilink
    arrow-up
    46
    ·
    1 year ago

    GIMP’s UI is what’s holding it back.

    If it was remotely near inkscape’s usability, it would be way more popular. The script that tries to make it look like Photoshop, shows GIMP’s underlying limitations.

    GIMP should go straight to phase 3.

    • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍@midwest.social
      link
      fedilink
      arrow-up
      23
      arrow-down
      1
      ·
      1 year ago

      GIMP makes uncommon things possible, and common things hard. I really don’t understand the mental model of people (the devs) who think the GIMP UI is intuitive. It’s such a powerful, widely used program, I have always thought it was just me, not understanding some paradigm. But Photoshop is as or more powerful, and yet is so much easier to work with. And it isn’t only casuals using Photoshot; professionals do too, so it’s not just that GIMP is designed for power users.

      I honestly don’t understand how the GIMP UI can be so consistently and enduringly difficult.

      Draw a straight line with GIMP. I dare you.

    • Footnote2669@lemmy.zip
      link
      fedilink
      arrow-up
      20
      ·
      1 year ago

      I started off on GIMP, decided to try Photoshop…. How… how can I come from software I have more experience with, and find it easier to work in Photoshop? As much as I want to love GIMP, damn the UX is ass

      • fakeman_pretendname@feddit.uk
        link
        fedilink
        arrow-up
        5
        ·
        1 year ago

        I love Kdenlive, though it’s always worth keeping an eye on Openshot, Olive, Shotcut etc.

        Is there any scope to allow the interoperability to work with multiple software on each end (i.e. Gimp or Krita with Kdenlive or Olive) - or does it complicate things too much?

        • Schola@lemmings.worldOP
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          Yes, that’s the goal, am pretty sure that it’s a O(n)² problem though so it’s definitely a challenge.

  • fakeman_pretendname@feddit.uk
    link
    fedilink
    arrow-up
    11
    ·
    1 year ago

    This is definitely something that’s needed, so thanks for taking the initiative to start something :)

    Just to note, your front page suggests darktable as an Illustrator replacement - whereas I would have said Inkscape is the Illustrator replacement (they are both vector graphic editors) and that Darktable is for processing raw digital photographs.

  • indigomirage@lemmy.ca
    link
    fedilink
    arrow-up
    11
    ·
    1 year ago

    I’m interested to see how this project turns out.

    Honestly, Adobe is is one of two main reasons I have not had success switching (back) to Linux. The secret sauce with Adobe Lightroom (Classic and CC) is the ability to take pics from any device (phone, old DSLR w/manual imports, downloads) and edit from my phone, or desktop seamlessly regardless of source, all in same catalogue, with non-destructive edits sync’d bidirectionally. I also get all originals sync’d tho main computer to merge in with my overall backup strategy. None of the open source offerings have this, though I keep checking in on it every few years. I’m sure Darktable is great - it may even be better than LR, but without the easy interoperability/synchronization, it’s not viable in my situation. I would not expect a solution like this to be free. I’m happy to pay for it. If Adobe offered real Linux compatibility, I’d pay for it in a heartbeat (and would gladly switch to a different company if it existed).

    For video other graphic stuff, I can live with the silos and happily run Shotcut (or KDENLive) and Krita.

    If it wasn’t for my other windows dependency, I’d switch and get by with running Lightroom virtually, and put up with the loss of other applications/features (on the Linux host) that I can live without.

    (My other dependency is NI Maschine (music production). The hardware - and the feature set I’ve paid for and use simply won’t run on Linux. I briefly considered running it virtually in Windows but ended up giving my head a shake because of the Rube Goldberg machine I’d end up making to have anywhere close to the functionality I have now).

    I’d be thrilled to switch back to Linux (I used it for years as a daily driver).

      • indigomirage@lemmy.ca
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        1 year ago

        Yes - it certainly is weaker than the desktop (classic) LR, but it matches the mobile app quite well (and syncs to the desktop). This is the secret sauce. I can do simple smartphone pics, edit them and they will merge with main catalog. I can further refine on desktop (or vice versa) and it all syncs, and my originals stay with the desktop (the further backed up via whatever mechanism I want).

        I applaud the idea of interoperability for the FOSS applications, but pulling this particular feat (the use case I describe above) off is non-trivial and requires enterprise level architecture and coordination. It’s a very different type of challenge than making a great non-destructive editor with local organization. I don’t mind paying for this sort of thing, but I wish it was officially offered in Linux-land. Wine is great (if it works) but it injects a substantial risk of breaking as applications get updated.

        Would love to run Linux everywhere, but there needs to be official support from some key companies for that to happen. It’s a difficult thing for them to justify (rightly or wrongly). I don’t think open-source alone will solve things. Unfortunately…

        Oh well - I got off topic here. But I was toying with trying another switch to Linux just this weekend and this is front of mind…

  • fartsparkles@sh.itjust.works
    link
    fedilink
    arrow-up
    9
    ·
    1 year ago

    So all they have is a boilerplate script that doesn’t do anything yet?

    I’d rather see this as a collaborative effort between upstream rather than a “layer” of scripts, not to mention their “phase 3” is forking upstream which we really don’t need.

    I’d rather see this project’s team simply working with upstream and sending PRs / patches.

    • Schola@lemmings.worldOP
      link
      fedilink
      arrow-up
      10
      ·
      1 year ago

      they

      Am only one person :), but if anybody is interested in helping, I would love that, I can easily add you to be a member.

      so all they have is a boilerplate script that doesn’t do anything yet?

      Fair, I wrote that quickly as a starting point.

      I’d rather see this project’s team simply working with upstream and sending PRs / patches.

      Noted, am still thinking on the best way to approach this “interoperability” problem.

      • fartsparkles@sh.itjust.works
        link
        fedilink
        arrow-up
        20
        ·
        edit-2
        1 year ago

        I love your passion but I think you published on GitHub a little too soon. Rather than pitch solutions, keep it to the problem space definition for now.

        Then, reach out to the upstream developers and see what their thoughts are and how you can contribute. I’m sure there is definitely space for a interoperability library that makes it easy for any creative FOSS app to integrate and enter into this open ecosystem concept but rather than inventing it for upstream, you should invent it with upstream.

        Good luck and stay this passionate - the FOSS community needs people like you!

  • Helix 🧬@feddit.de
    link
    fedilink
    English
    arrow-up
    13
    arrow-down
    4
    ·
    1 year ago

    Reproducible scripts are scripts using Nix so that we don’t have the problem of “It works in my machine”

    Ok, no, thanks. This should work on all distributions with their package managers instead of needing a separate layer. The approach to first package it and then write addons is a bit weird.

    • Atemu@lemmy.ml
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      That’s the thing with Nix: It works on all the distros.

      Distros could of course also package it themselves (nothing preventing them from doing that) but having a baseline in Nix that you can point to makes the distro’s job easier here aswell. If it works via Nix but doesn’t in xyz distro’s package, you know where the problem lies.

      • Helix 🧬@feddit.de
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        edit-2
        1 year ago

        That’s the thing with Nix: It works on all the distros.

        … as long as you install Nix.

        You could say the same about Docker, Flatpak, AppImage or even Snap. Nix is nothing special in that regard.

        • Atemu@lemmy.ml
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          Nix is nothing special in that regard.

          Well, with the exception that all of those tools use userns to ship almost a full userspace tree while Nix uses no containerisation whatsoever to do its job.

  • elliot_crane@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    1 year ago

    Just a heads up, all of the reference links are busted as far as I can tell.

    I’m 99% for markdown you want to do:

    Lorem ipsum dolor sit amet [link text][unique name][unique name]: website URL
    
    

    Edit: removed actual URL because my Lemmy client was formatting it for markdown lol